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

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 の Security Architecture ドキュメントをお読みください。また、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 つの用語の置き換えから始めます。この取り組みは膨大な作業を要するため、今後の複数のリリースで段階的に用語の置き換えを実施して参ります。詳細は、弊社 の 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. source-address-role-decoderelytron サブシステムへの追加

管理 CLI または管理コンソールを使用して、source-address-role-decoder ロールデコーダーを elytron サブシステムに追加できます。このロールデコーダーを mappers 要素に設定すると、承認決定を行うときにクライアントの IP アドレスを使用します。

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

注記

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

前提条件

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

手順

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

    source-address-role-decodermappers 要素に追加する例:

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

    この例では、decoder 1 という名前が付けられた、設定済みの source-address-role-decoder を示しています。クライアントがサーバーへの接続を試みると、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 を使用するようになります。

    role- decoder 属性で、設定済みの source-address-role -decoder 1 を参照する例:

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

関連情報

  • 管理コンソールでロールデコーダーを追加する方法は、「 Elytron サブシステム 」を参照してください。
  • elytron サブシステムに関する詳細は、『 セキュリティーアーキテクチャー 』の「 Elytron サブシステム 」を参照してください。

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

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

前提条件

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

手順

  • aggregate-role-decoder ロールデコーダーに、2 つ以上のロールデコーダーを追加します。

    decoder1 および decoder 2aggregate-role-decoder ロールデコーダーに追加する例:

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

関連情報

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 EAP『 How to Configure Identity Management』の「 Configure Client Authentication with Elytron Client 」を参照してください。

注記

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『 How to Configure Identity Management』の「 Configure Client Authentication with Elytron Client 」を参照してください。

管理 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,algorithm="PKIX",credential-reference={clear-text=secret})
重要

アルゴリズムが指定されていない場合は、デフォルトの KeyManagerFactory アルゴリズム名に設定されます。

使用できるキーマネージャーアルゴリズムは、使用中の JDK によって提供されます。たとえば、SunJSSE を使用する JDK は、PKIX および 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 を使用するようにアプリケーションを設定するには、『 How to Configure Identity Management Guide』の「Configure Web Applications to Use Elytron or Legacy Security for Authentication 」を参照してください。また、JBoss EAP『 How to Configure Identity Management Guide』 の「 Override an Application's Authentication Configuration 」の手順に従って、すべてのアプリケーションのデフォルトの動作を上書きできます。

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 セキュリティードメインでバッチジョブを実行することができます。詳細は、『Configuration Guide』の「 Configure Security for Batch Jobs 」を参照してください
datasources
クレデンシャルストアまたは Elytron セキュリティードメインを使用することで、データソース定義に認証情報を提供できます。詳細は、『 設定ガイド』の 「データソース セキュリティー」を参照してください
ejb3
Elytron セキュリティードメインのマッピングを ejb3 サブシステムで作成し、デプロイメントによって参照されるようにすることができます。詳細は、『 Jakarta Enterprise Beans アプリケーションの開発』の「 Elytron Integration with the EJB Subsystem 」を参照してください
iiop-openjdk
elytron サブシステムを使用することで、iiop-openjdk サブシステムを使用してクライアントとサーバーの間で SSL/TLS を設定できます。詳細は、『 設定ガイド』の「 Elytron サブシステムで SSL/TLS を使用するよう IIOP を設定」を参照してください
jca
elytron-enabled 属性を使用して、ワークマネージャーの Elytron セキュリティーを有効にできます。詳細は、『 設定ガイド』 の「JCA サブシステムの設定 」を参照してください
jgroups
SYM_ENCRYPT および ASYM_ENCRYPT プロトコルを設定して、elytron サブシステムで定義されたキーストアまたは認証情報リファレンスを参照できます。詳細は、『 設定ガイド』の「 クラスターのセキュア化 」を参照してください
mail
認証情報ストアを使用することで、mail サブシステムのサーバー定義に認証情報を指定できます。詳細は、『Configuration Guide』の「 Use a Credential Store for Passwords 」を参照してください
messaging-activemq
messaging-activemq サブシステムで使用されるリモート接続へのリモート接続を保護することができます。詳細は、『 Configuring Messaging 』の「 Using the 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 を使用してリソースアダプターへの接続をセキュアにすることができます。作業マネージャーによって実行される作業を送信するときに、セキュリティインフローを有効にしてセキュリティ資格情報を確立できます。詳細は、『Configuration Guide』の「 Configure Resource Adapters to Use the Elytron Subsystem 」を参照してください
undertow
elytron サブシステムを使用すると、SSL/TLS とアプリケーション認証の両方を設定できます。アプリケーション認証の設定に関する詳細は、『 How to Configure Identity Management 』の「 SSL/TLS の使用 」および「Configure Web Applications to Use Elytron or Legacy Security for Authentication 」を参照してください。

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. Security サブシステムの有効化および無効化

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

/subsystem=security:remove
重要

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

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

/subsystem=security:add

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

JBoss EAP はセキュリティーレルムを使用して、ローカル、LDAP、プロパティーなどの認証および承認メカニズムを定義します。セキュリティーレルムの背景情報は、Red Hat JBoss Enterprise Application Platform『 セキュリティーアーキテクチャー 』の「 セキュリティーレルム 」を参照してください。

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

<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. 管理インターフェースのセキュア化に認証とソケットバインディングを使用する

デフォルトでは、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
    }
}

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

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 はさまざまなホスト、ネットワーク、およびファイアウォール要件で使用できます。

JBoss EAP が使用するネットワークおよびポートや、これらの設定の設定方法は、JBoss EAP『 設定ガイド』の「ネットワークおよびポート設定 」を参照してください

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

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

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

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

jmx サブシステムへのリモートアクセスにより、JDK とアプリケーション管理操作がリモートでトリガーできます。JBoss EAP で Jakarta Management へのリモートアクセスを無効にするには、jmx サブシステムの リモーティングコネクターを削除します。

リモーティングコネクターの削除
/subsystem=jmx/remoting-connector=jmx/:remove

Jakarta Management の詳細は、『Red Hat JBoss Enterprise Application Platform Security Architecture』ガイドの「 Jakarta Management 」を参照してください。

1.2.4. サイレント認証

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

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

重要

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

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"
    }
}

/subsystem=elytron/sasl-authentication-factory=temp-sasl-authentication:list-remove(name=mechanism-configurations,index=0)

reload

レガシーセキュリティーレルムの使用時にサイレント認証を削除するには、以下を行います。

/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 を以下の方法で有効にできます。

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

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

例: ウィザードの使用

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 がサーバーを再読み込みし、そのサーバーに再接続します。

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

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,algorithm="SunX509",credential-reference={clear-text=secret})
    
    /subsystem=elytron/server-ssl-context=httpsSSC:add(key-manager=httpsKM,protocols=["TLSv1.2"])
    重要

    使用している JDK によるキーマネージャーアルゴリズムを知る必要があります。たとえば、SunJSSE を使用する JDK は、PKIX および 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 設定を使用します。

注記

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

security disable-ssl-management

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

管理コンソールの使用

管理コンソールで使用する管理インターフェースに対して 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 を有効化する

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

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

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

      注記

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

      例: ウィザードの使用

      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 認証を完了するには、サーバーの証明書をクライアントトラストストアにインポートし、クライアント証明書を表示するようにクライアントを設定する必要があります。

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

      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,algorithm="SunX509")
        
        /subsystem=elytron/server-ssl-context=twoWaySSC:add(key-manager=twoWayKM,protocols=["TLSv1.2"],trust-manager=twoWayTM,want-client-auth=true,need-client-auth=true)
        重要

        使用している JDK によるキーマネージャーアルゴリズムを知る必要があります。たとえば、SunJSSE を使用する JDK は、PKIX および SunX509 アルゴリズムを提供します。また、使用する HTTPS プロトコルを決定する必要もあります。上記のコマンド例は TLSv1.2 を使用します。cipher-suite-filter 引数を使用して、許可される暗号スイートを指定でき、use-cipher-suites-order 引用して、サーバーの暗号スイートの順序を許可します。use-cipher-suites-order 属性はデフォルトで true に設定されます。これは、レガシー security サブシステムの動作とは異なります。その動作は、デフォルトで、クライアント暗号スイートの順序を許可します。

        1. 管理インターフェースで 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)
        2. JBoss EAP インスタンスをリロードします。

          reload
          注記

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

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

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

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

          元の認証方法を変更する場合は、JBoss EAP『 How to Configure Identity Management』の「 Configure Authentication with Certificates 」を参照してください。

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

重要

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

注記

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

security disable-ssl-management

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

1.2.7. CLI セキュリティーコマンドを使用した管理インターフェースの 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 reorder-sasl-management --mechanisms-order=MECHANISM1,MECHANISM2,...
管理インターフェースの SASL 認証の無効化

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

security disable-sasl-management

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

security disable-sasl-management --mechanism=MECHANISM

1.2.8. CLI セキュリティーコマンドを使用した管理インターフェースの 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 を有効にする手順を実行すると、明示的に指示しない限り、設定は再読み込みされません。これを実行すると、管理インターフェースがロックされる可能性があります。

管理インターフェースをセキュア化するためのキーストアの作成
注記

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

以下を実行してキーストアを生成します。パラメーターの例の値 (例: 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 年と等しくなります。

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

スタンドアロンサーバーの実行

管理インターフェイスが 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)
オプション: カスタム 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}"
    }
}
新しいセキュリティーレルムの作成

この例では、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
    重要

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

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

以下の管理 CLI コマンドを使用して、新しいセキュリティーレルムを使用するよう管理インターフェースを設定します。

/core-service=management/management-interface=http-interface:write-attribute(name=security-realm,value=ManagementRealmHTTPS)
キーストアを使用するように管理インターフェースを設定

以下の管理 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)

このときは、サーバーの設定をリロードする必要があります。

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 が再接続できるようにします。

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

管理 CLI を使用して管理アクションを実行する場合は、以下の変更を 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 サブシステムの属性 」を参照してください

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. OpenSSL プロバイダーを使用した TLS 1.3 プロトコルのサポートの有効化

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

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

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

前提条件

  • アプリケーションに一方向 SSL/TLS または双方向 SSL/TLS を有効にします。

手順

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

    1. デフォルトでは OpenSSL TLS プロバイダーを使用するように elytron サブシステムを設定します。これには、グローバルに登録されているプロバイダーをすべて登録した後に OpenSSL TLS プロバイダーを登録するデフォルトの final-providers 設定を削除します。

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

      次に、グローバルに登録されたすべてのプロバイダーの前に OpenSSL TLS プロバイダーを登録します。

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

      server SSC と呼ばれる既存の server-ssl-contextproviders 属性を設定する例

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

  2. 必要に応じて、TLS 1.3 プロトコル以外のプロトコルを使用するように ssl-context を設定している場合、TLS 1.3 プロトコルを含めるように ssl-contextprotocols 属性を設定する必要があります。

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

    /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>

    SSL 接続のセキュリティーを保護するために、TLS 1.3 プロトコルのある TLS_AES_256_GCM_SHA384 の出力例。

    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

    注記
    • RHEL 7 以前のデフォルトのデータベース形式である 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="X509" key-store-name="keystore">
              <key-store-clear-password password="${password"} />
            </key-store-ssl-certificate>
            <trust-store key-store-name="truststore"/>
            <trust-manager algorithm="X509">
            </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="X509",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="SunX509" 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.3.1. Elytron 監査ロギング

elytron サブシステムの監査ロギングは、アプリケーションサーバー内の Elytron 認証および承認イベントのロギングを有効にします。監査ログエントリーは、人間が読むことのできる JSON または SIMPLE のいずれかの形式で保存されます。デフォルトでは、Elytron では監査ロギングが無効になっています。

監査ロギングは、Elytron の以下の任意のログハンドラーを設定し、必要なセキュリティードメインに追加することで有効にできます。

重要

Elytron 監査ロギングは、JBoss EAP 管理インターフェースの監査ロギングなど、他の監査ロギングとは異なります。管理インターフェース監査ロギングオプションの詳細は、JBoss EAP『 設定ガイド』 「管理監査ロギング」を参照してください

ファイル監査ロギング

ファイルの監査ロギングでは、監査ログメッセージを複数のファイルに分割せずに、ファイルシステムにある指定のファイルに保存します。

local-audit という名前の Elytron ファイル監査ロガーは、デフォルトで定義されています。有効にすると、Elytron 監査ログがスタンドアロンサーバーの EAP_HOME/standalone/log/audit.log または、管理対象ドメインのホストの EAP_HOME/domain/log/audit.log に書き込まれます。

ファイル監査ロガーの属性は次のとおりです。

  • pathrelative-to: ログファイルの場所を定義します。
  • autoflush: すべての監査イベントの後に出力ストリームがフラッシュされるかどうかを指定します。この属性が定義されていない場合は、synchronized の値を使用します。
  • synchronized: すべての監査イベントの後にファイル記述子を同期すべきかどうかを指定します。デフォルトは true です。
  • format: 人間が読むことのできるテキスト形式 SIMPLE、または JSON で個別のイベントを保存するための JSON を使用します。

    1. 以下のようなコマンドを使用してファイル監査ログを作成できます。

      /subsystem=elytron/file-audit-log=my_audit_log:add(path="my_audit.log",relative-to="jboss.server.log.dir",format=SIMPLE,synchronized=true)
    2. 定義したファイル監査ロガーは、セキュリティドメインに追加して有効化します。

      /subsystem=elytron/security-domain=domain-with-file-logger:write-attribute(name=security-event-listener, value=my_audit_log)
定期的なローテーションファイル監査ロギング

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

  • suffix: これは java.text.SimpleDateFormat 形式である必要があります。例: .yyyy-MM-dd-HHローテーションの期間はこのサフィックスに基づいて自動的に算出されます。このサフィックスは、ログファイル名の末尾に追加されます。

    1. 以下のようなコマンドを使用して、ファイル監査ログを定期的にローテーションできます。

      /subsystem=elytron/periodic-rotating-file-audit-log=my_periodic_audit_log:add(path="my_periodic_audit.log",relative-to="jboss.server.log.dir",format=SIMPLE,synchronized=false,suffix=".yyyy-MM-dd-HH")
    2. 定義した定期的なローテションファイルは、セキュリティドメインに追加することで有効にできます。

      /subsystem=elytron/security-domain=domain-with-periodic-file-logger:write-attribute(name=security-event-listener, value=my_periodic_audit_log)
サイズローテーションファイル監査ロギング

ログファイルが設定されたファイルサイズに達すると、サイズローテーションファイル監査ログにより自動的に監査ログのローテーションが行われます。これは、以下の追加属性とともに、デフォルトの ファイル監査ロガーと同じ基本的な属性を持ちます。

  • rotate-size: ログファイルの最大サイズです。この値を超えるとファイルがローテーションされます。デフォルトは 2 メガバイトを意味する 2m です。
  • max-backup-index: ローテーションを行う際にバックアップする最大ファイル数。
  • rotate-on-boot: デフォルトでは、サーバーの再起動時に新しいログファイルは作成されません。サーバーの再起動時にログをローテーションするには、true に設定します。
  • suffix: これにより、日付の接尾辞がローテーションログに追加されます。これは、. yyyy-MM-dd-HH のように java.text.SimpleDateFormat 形式である必要があります。

ログファイルのサイズが rotate-size 属性で定義された制限を超えると、接尾辞 .1 が現在のファイルの末尾に追加され、新しいログファイルが作成されます。既存のログファイルがある場合は、接尾辞の付いた番号が 1 つずつ増えます。たとえば、audit_log.1audit_log.2 に変わります。これは、max-backup-index で定義されているログファイルの最大数に達するまで行われます。max-backup-index を超過すると、制限を超えたファイル (audit_log.99) が削除されます。

  1. 以下のようなコマンドを使用して、サイズローテーションファイル監査ログを作成できます。

    /subsystem=elytron/size-rotating-file-audit-log=my_size_log:add(path="my_size_audit.log",relative-to="jboss.server.log.dir",format=SIMPLE,synchronized=false,rotate-size="2m",max-backup-index=10)
  2. セキュリティードメインに追加して、定義されたサイズローテーション監査ロガーを有効にします。

    /subsystem=elytron/security-domain=domain-with-size-logger:write-attribute(name=security-event-listener, value=my_size_log)
syslog 監査ロギング

syslog ハンドラーは、監査ログエントリーが syslog サーバーに送信されるときのパラメーター (syslog サーバーのホスト名および syslog サーバーがリッスンするポート) を指定します。監査ロギングを syslog サーバーへ送信すると、ローカルファイルまたはローカル syslog サーバーへロギングする場合よりも、セキュリティーオプションが多くなります。複数の syslog ハンドラーを同時に定義およびアクティブ化することができます。

syslog ロガーが初めて定義されると、ロガーは INFORMATIONAL 優先度イベントを、メッセージを含む syslog サーバーに送信します。

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

<format> は、監査ロギングハンドラー用に設定される RFC 形式で、デフォルトでは RFC5424 に設定されます。

対応ログ形式:

対応転送プロトコル:

  • UDP
  • TCP
  • SSL を使用した TCP

syslog-audit-log 属性の一覧は、「syslog -audit-log 属性 」を参照してください。

手順

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

    /subsystem=elytron/syslog-audit-log=syslog-logger:add(host-name=HOST_NAME, port=PORT, server-address=SERVER_ADDRESS, format=JSON, transport=UDP)
  2. 定義した syslog 監査ロガーは、セキュリティドメインに追加して有効化します。

    /subsystem=elytron/security-domain=domain-with-syslog-logger:write-attribute(name=security-event-listener, value=syslog-logger)
重要

TLS 経由でログを syslog サーバーに送信するには、以下の設定を追加します。

/subsystem=elytron/syslog-audit-log=remote-audit:add(transport=SSL_TCP,server-address=127.0.0.1,port=9898,host-name=Elytron,ssl-context=audit-ssl)
注記

セキュリティーイベントをより多くの宛先 (得にロガー) に送信するには、aggregate-security-event-listener リソースが使用されます。これにより、すべてのイベントが集約リスナー定義に指定されたすべてのリスナーに提供されます。

1.3.1.1. Elytron のカスタムのセキュリティーイベントリスナー

カスタムのイベントリスナーを定義して、受信セキュリティーイベントの処理方法を調整できます。このイベントリスナーは、カスタム監査ロギングに使用できます。または内部アイデンティティーストレージに対してユーザーを認証できます。

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

    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());
            }
        }
    }
  2. Add a Custom Component to Elytron で説明されているように、カスタムイベントリスナーをモジュールとして JBoss EAP に提供する JAR を追加します。以下に、カスタムイベントリスナーをモジュールとして Elytron に追加する管理 CLI コマンドの例を示します。

    /subsystem=elytron/custom-security-event-listener=LISTENER_NAME:add(module=MODULE_NAME, class-name=CLASS_NAME)
    重要

    module 管理 CLI コマンドを使用したモジュールの追加および削除は、テクノロジープレビューとしてのみ提供されます。このコマンドは、管理対象ドメインでの使用や、リモートによる管理 CLI への接続時には適していません。本番環境では、モジュールを手作業で追加および削除する必要があります。詳細は、JBoss EAP『 設定ガイド』の「 カスタムモジュールの手動作成 」および 「カスタムモジュールの手動削除 」を参照してください

    テクノロジープレビューの機能は、Red Hat の本番環境のサービスレベルアグリーメント (SLA) ではサポートされず、機能的に完全ではないことがあるため、Red Hat は本番環境での使用は推奨しません。テクノロジープレビューの機能は、最新の技術をいち早く提供して、開発段階で機能のテストやフィードバックの収集を可能にするために提供されます。

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

  3. ApplicationDomain などのセキュリティードメインから新たに定義されたリスナーを参照します。

    /subsystem=elytron/security-domain=DOMAIN_NAME:write-attribute(name=security-event-listener, value=LISTENER_NAME)
  4. 提供されたセキュリティードメインから、受信セキュリティーイベント開始するようにサーバーをリロードします。

    reload

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

監査モジュールの目標は、security サブシステムでイベントを監視する手段を提供することです。この監視は、ログファイル、電子メール通知、またはその他の測定可能な監査メカニズムに書き込む方法で実行できます。

監査は、プロバイダーモジュールを使用します。含まれるプロバイダーモジュールとカスタム実装の両方を使用できます。

セキュリティードメインのセキュリティー監査設定を設定するには、管理コンソールから以下の手順を実行する必要があります。

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

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

1.4.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.4.2. Elytron の使用

1.4.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, algorithm="SunX509", credential-reference={clear-text=secret})
    重要

    使用している JDK によるキーマネージャーアルゴリズムを知る必要があります。たとえば、Sun valueFrom を使用する JDK では PKIX アルゴリズムおよび SunX 509 アルゴリズムを利用できます。

    上記のコマンド例は、キーマネージャーアルゴリズムに 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.4.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, algorithm="SunX509", credential-reference={clear-text=secret})
        重要

        使用している JDK によるキーマネージャーアルゴリズムを知る必要があります。たとえば、Sun valueFrom を使用する JDK では PKIX アルゴリズムおよび SunX 509 アルゴリズムを利用できます。

        以下のコマンド例は、キーマネージャーアルゴリズムに SunX509 を使用します。

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

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

        使用している JDK によるキーマネージャーアルゴリズムを知る必要があります。たとえば、Sun valueFrom を使用する JDK では PKIX アルゴリズムおよび SunX 509 アルゴリズムを利用できます。

        上記のコマンド例は、キーマネージャーアルゴリズムに SunX509 を使用します。

      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『 How to Configure Identity Management』の「 Configure Authentication with Certificates 」を参照してください。

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

注記

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

security disable-ssl-http-server

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

1.4.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.4.4. Elytron で 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.4.5. レガシーセキュリティーレルムの使用

重要

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

1.4.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.4.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 インスタンスに接続している場合は、その証明書またはキーストアをブラウザーの証明書マネージャーにインポートする必要があります。

注記

アプリケーションでの証明書ベースの認証の使用に関する詳細は、JBoss EAP『 How to Configure Identity Management Guide』の 「Configuring a Security Domain to Use Certificate-based Authentication 」を参照してください

1.5. 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.5.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.6. SASL の認証メカニズム

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

1.6.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.6.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.6.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/TLS Between Domain and Host Controllers Using 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 クライアントでのクライアント認証の設定の詳細は、「 How to Configure Identity Management 」を参照してください。

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.6.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.7. Elytron の ModCluster サブシステムとの統合

elytron サブシステムによって公開されるセキュリティー機能は、SSL/TLS を使用してロードバランサーと通信するように modcluster サブシステムを設定するのに使用できるクライアント ssl-context です。

アプリケーションサーバーとロードバランサー間の通信を保護する場合は、以下を行うためにクライアント ssl-context を定義する必要があります。

  • ロードバランサーの証明書の検証に使用される証明書チェーンを保持するトラストストアを定義する。
  • ロードバランサーの証明書に対して検証を実行するためのトラストマネージャーを定義する。

1.7.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.8. Elytron の JGroups サブシステムとの統合

jgroups サブシステムで承認プロトコルまたは暗号化プロトコルを定義するときに elytron サブシステムのコンポーネントが参照されることがあります。これらのプロトコルの設定方法は『 設定ガイド 』の「クラスターのセキュア化 」を参照してください

1.9. Remoting サブシステムとの Elytron の等号

1.9.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.9.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 メカニズムを指定できます。

前提条件

  • key-store が設定されている。
  • key-manager が設定されている。
  • 定義した key -manager を参照する 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.9.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-store コンポーネントが設定されます。
  • サーバー key- store の key- manager が設定されている。
  • サーバー trust- store の trust- manager が設定されている。
  • 定義した key -manager および trust-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.9.2. Elytron のリモーティング HTTP コネクターとの統合

リモート 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.9.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.9.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.9.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.10. 管理対象ドメインのセキュア化

管理インターフェースをセキュア化する他に、管理対象ドメインの JBoss EAP インスタンス間の通信をセキュアにすることもできます。

管理対象ドメイン操作モードの概念および一般的な設定の詳細は、JBoss EAP『 設定ガイド』の「 ドメイン管理 」を参照してください

1.10.1. Elytron を使用した、スレーブとドメインコントローラー間でのパスワード認証の設定

  1. マスタードメインコントローラーでユーザーを追加します。

    スレーブコントローラーが認証に使用するには、マスタードメインコントローラーにユーザーを追加する必要があります。デフォルトのファイルベースユーザーおよびグループ認証メカニズムを使用している場合は、EAP_HOME/bin/adduser.sh を実行することで実行できます。プロンプトが表示されたら、ユーザー名、パスワード、およびその他の設定を追加します。

    add-user ユーティリティーを使用すると、ManagementRealm のユーザーと、ApplicationRealm のユーザーの両方を管理できます。

    注記

    サーバーは、メモリー内のプロパティーファイルの内容をキャッシュします。ただし、サーバーは認証リクエストごとにプロパティーファイルの変更時間を確認し、時間が更新された場合にリロードします。つまり、add-user ユーティリティーによるすべての変更が稼働中のサーバーに即座に適用されることになります。

    スレーブコントローラーは、HTTP インターフェースを使用した認証を試行します。HTTP インターフェースが ManagementRealm Elytron セキュリティーレルムで保護されている場合は、スレーブコントローラーが使用する ManagementRealm にユーザーを追加する必要があります。

    注記

    管理ユーザーのレルムのデフォルト名は ManagementRealm です。add-user ユーティリティーがレルム名の入力を要求したときに、別のレルムに切り替えていない限りデフォルトのものを許可します。

    以下の例では、パスワード password1! が設定されたユーザー slaveManagementRealm に追加済みであることを前提としています。

  2. 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>

1.10.2. レガシーコア管理認証を使用したスレーブとドメインコントローラーのパスワード認証の設定

管理対象ドメインを設定する場合は、デフォルトでマスタードメインコントローラーが、接続する各スレーブコントローラーに認証を必要とするよう設定されます。スレーブのコントローラーを適切な認証情報で設定するには、以下を行う必要があります。

  1. マスタードメインコントローラーにユーザーを追加します。

    add-user スクリプトを使用して、ユーザーをマスタードメインコントローラーに追加する必要があります。具体的には、マスターが管理インターフェースをセキュア化するために使用する同じレルムにユーザーを追加する必要があります (デフォルトでは ManagementRealm)。また、「Is this new user going to be used for one AS process to connect to another AS process?」(この新しいユーザーは、ある AS プロセスが別の AS プロセスに接続するために使用されますか ?) という質問に必ず yes と回答する必要があります。

    重要

    ユーザーを追加すると、スクリプトは次のステップで使用される <secret> 要素を出力します。この値は、次の手順で使用するために維持する必要があります。

    例: スレーブユーザーの追加

    $ 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" />

  2. クレデンシャルを使用するようにスレーブコントローラーを設定します。

    マスタードメインコントローラーでユーザーを作成したら、ホスト設定ファイル (例: host.xml または host-slave.xml) で、その認証ファイルを使用するように各スレーブコントローラーを更新する必要があります。これを行うには、ドメインコントローラー設定の <remote> 要素にユーザー名を追加する必要があります。<remote> 要素をセキュア化するために使用されるレリムの server identities<secret> を追加する必要があります。直前の手順でユーザーをマスタードメインコントローラーに追加する際に、ユーザー名と <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>

1.10.3. Elytron を使用したドメインコントローラーとホストコントローラー間の SSL/TLS の設定

重要

管理対象ドメインの JBoss EAP インスタンス間で使用する SSL/TLS を設定する場合は、対話に応じて各インスタンスにクライアントまたはサーバーのロールを設定できます。これには、すべてのホストコントローラーとドメインコントローラーが含まれます。そのため、エンドポイント間に双方向 SSL/TLS を設定することが推奨されます。

マスタードメインコントローラーとホストコントローラー間で相互に通信する際に SSL / TLS を使用するように管理対象ドメインの JBoss EAP インスタンスを設定できます。Elytron を使用する場合は、以下の手順を使用します。

  1. 必要なすべての証明書およびキーストアを生成して設定します。

    エンドポイント間で双方向 SSL/TLS を設定するには、マスタードメインコントローラーおよび各ホストコントローラーの証明書およびキーストアを生成し、設定する必要があります。マスタードメインコントローラーの証明書を各ホストコントローラーのキーストアにインポートし、各ホストコントローラーの証明書をマスタードメインコントローラーのキーストアにインポートする必要があります。このプロセスの詳細は、「Elytron サブシステムを使用した管理インターフェースの方向 SSL/TLS の有効化 」を参照してください。

  2. マスタードメインコントローラーでユーザーを追加します。

    スレーブコントローラーが認証に使用するには、マスタードメインコントローラーにユーザーを追加する必要があります。デフォルトのファイルベースユーザーおよびグループ認証メカニズムを使用している場合は、EAP_HOME/bin/adduser.sh を実行することで実行できます。プロンプトが表示されたら、ユーザー名、パスワード、およびその他の設定を追加します。

    add-user ユーティリティーを使用すると、ManagementRealm のユーザーと、ApplicationRealm のユーザーの両方を管理できます。

    注記

    サーバーは、メモリー内のプロパティーファイルの内容をキャッシュします。ただし、サーバーは認証リクエストごとにプロパティーファイルの変更時間を確認し、時間が更新された場合にリロードします。つまり、add-user ユーティリティーによるすべての変更が稼働中のサーバーに即座に適用されることになります。

    スレーブコントローラーは、HTTP インターフェースを使用した認証を試行します。HTTP インターフェースが ManagementRealm Elytron セキュリティーレルムで保護されている場合は、スレーブコントローラーが使用する ManagementRealm にユーザーを追加する必要があります。

    注記

    管理ユーザーのレルムのデフォルト名は ManagementRealm です。add-user ユーティリティーがレルム名の入力を要求したときに、別のレルムに切り替えていない限りデフォルトのものを許可します。

    以下の例では、パスワード password1! が設定されたユーザー slaveManagementRealm に追加済みであることを前提としています。

  3. マスタードメインコントローラーを、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,algorithm="SunX509",credential-reference={clear-text=secret})
    
    /host=master/subsystem=elytron/trust-manager=twoWayTM:add(key-store=twoWayTS,algorithm="SunX509")
    
    /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)
    重要

    使用している JDK によるキーマネージャーアルゴリズムを知る必要があります。たとえば、SunJSSE を使用する JDK は、PKIX および SunX509 アルゴリズムを提供します。また、使用する HTTPS プロトコルを決定する必要もあります。上記のコマンド例は TLSv1.2 を使用します。cipher-suite-filter 引数を使用して、許可される暗号スイートを指定でき、use-cipher-suites-order 引用して、サーバーの暗号スイートの順序を許可します。use-cipher-suites-order 属性はデフォルトで true に設定されます。これは、レガシー security サブシステムの動作とは異なります。その動作は、デフォルトで、クライアント暗号スイートの順序を許可します。

  4. 各スレーブホストコントローラーに認証コンテキストとドメインコントローラーの場所を設定します。

    以下の設定例は、ドメインコントローラーが 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)
  5. 各スレーブホストコントローラーが 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,algorithm="SunX509",credential-reference={clear-text=secret})
    
    /host=slave1/subsystem=elytron/trust-manager=twoWayTM:add(key-store=twoWayTS,algorithm="SunX509")
    
    /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}])
  6. 管理対象ドメインのすべての JBoss EAP ホストをリロードします。

1.10.4. レガシーのコア管理認証を使用したドメインおよびホストコントローラー間の SSL/TLS の設定

重要

管理対象ドメインの JBoss EAP インスタンス間で使用する SSL/TLS を設定する場合は、対話に応じて各インスタンスにクライアントまたはサーバーのロールを設定できます。これには、すべてのホストコントローラーとドメインコントローラーが含まれます。そのため、エンドポイント間に双方向 SSL/TLS を設定することが推奨されます。

マスタードメインコントローラーとホストコントローラー間で相互に通信する際に SSL / TLS を使用するように管理対象ドメインの JBoss EAP インスタンスを設定できます。レガシーのコア管理認証を使用してこれを行うには、以下の手順に従います。

  1. 必要なすべての証明書およびキーストアを生成して設定します。

    エンドポイント間で双方向 SSL/TLS を設定するには、マスタードメインコントローラーおよび各ホストコントローラーの証明書およびキーストアを生成し、設定する必要があります。マスタードメインコントローラーの証明書を各ホストコントローラーのキーストアにインポートし、各ホストコントローラーの証明書をマスタードメインコントローラーのキーストアにインポートする必要があります。このプロセスの詳細は、「Setting up Two-way SSL/TLS for the Management Interfaces with Legacy Core Management Authentication」を参照してください。

  2. マスタードメインコントローラーを、SSL/TLS を使用するように設定します。

    すべての証明書とキーストアを設定したら、双方向 SSL/TLS を使用するようにセキュリティーレルムを設定する必要があります。これは、SSL/TLS を使用して、これを認証に必須するようにセキュリティレリムを設定することで実行されます。その後、そのセキュリティーレルムはホストコントローラーとマスタードメインコントローラー間の接続に使用される管理インターフェースのセキュア化に使用されます。

    注記

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

    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
  3. SSL/TLS を使用するようすべてのホストコントローラーを設定します。

    双方向 SSL/TLS を使用するようマスタードメインコントローラーを設定した場合は、各ホストコントローラーも使用するように設定する必要があります。このプロセスはマスタードメインコントローラーの設定とほぼ同じです。ただし、各ホストに固有のキーストアを使用する必要があります。

    注記

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

    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

    また、マスタードメインコントローラーの接続時に使用するセキュリティーレルムを更新する必要があります。この変更は、サーバーが動作していないときにホストコントローラーの設定ファイル (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>

    警告

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

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 認証情報を復号化することはできません。代わりに、認証情報は認証情報ストアを使用してセキュア化できます。

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 でのユーザー認証

2.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 サブシステムによって提供されるデフォルトのコンポーネントを使用して保護されるようになりました。

2.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"
        }
    }
}

2.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 セキュリティレリムは、ローカルユーザーに対するサイレント認証を処理します。

2.1.2. 新規アイデンティティーストアでの管理インターフェースのセキュア化

  1. アイデンティティーストアのセキュリティードメインおよびサポートするセキュリティーレルム、デコーダー、またはマッパーを作成します。

    このプロセスは、JBoss EAP『 How to Configure Identity Management Guide』 の「 Elytron Subsystem 」で説明されています。たとえば、ファイルシステムベースのアイデンティティーストアを使用して管理インターフェースのセキュリティーを保護する場合は、「 Configure Authentication with a Filesystem-based Identity Store 」の手順に従います。

  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 によって処理されます。

2.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『 How to Configure Identity Management Guide』の「 Elytron Subsystem 」を参照してください

重要

Elytron セキュリティーが使用され、実際のアイデンティティーに対応しない認証名で JBOSS-LOCAL-USER SASL メカニズムを使用して認証試行を行うと、認証は失敗します。

レガシー security サブシステムを使用すると、JBOSS-LOCAL-USER のカスタムユーザー名を選択できます。ユーザー名を特殊アイデンティティーにマッピングすることで、認証が続行されます。

2.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 にフィードされて現在のリクエストの管理ロールを取得します。

表2.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 リソースではサポートされていません。

2.1.5. 管理 CLI での Elytron クライアントの使用

管理 CLI は、JBoss EAP に接続する際にセキュリティー情報を提供するために Elytron Client を使用するように設定できます。

  1. Elytron で管理インターフェースを保護します。

    管理 CLI とともに Elytron クライアントを使用するには、管理インターフェースを Elytron でセキュアにする必要があります。Elytron で管理インターフェースをセキュア化する方法の詳細は、「Elytron でのユーザー認証」を参照してください。

  2. Elytron クライアント設定ファイルを作成します。

    認証設定が含まれる Elytron クライアント設定ファイルと、その設定を使用するためのルールを作成する必要があります。認証設定の作成の詳細は、JBoss EAP『 How to Configure Identity Management Guide』の「 Configuration File Approach 」を参照してください

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

2.2. Elytron でのアイデンティティー伝搬および転送

2.2.1. リモート呼び出しのセキュリティーアイデンティティーの伝搬

JBoss EAP 7.1 では、リモーティング呼び出しのためにクライアントからサーバーにセキュリティアイデンティティーを伝搬するためのサーバーとアプリケーションを簡単に設定できる機能が導入されました。指定のユーザーのセキュリティーアイデンティティー内で実行するようにサーバーコンポーネントを設定することも可能です。

本セクションの例では、セキュリティーアイデンティティーの認証情報を転送する方法を説明します。これは、クライアントおよび Jakarta Enterprise Beans のセキュリティーアイデンティティーをリモート Jakarta Enterprise Beans に伝播します。これは、ユーザーの承認されたロール情報とともにリモート Jakarta Enterprise Beans を呼び出した Principal の名前が含まれる文字列を返します。この例では、以下のコンポーネントで構成されています。

  • 呼び出し元に関する承認情報を返す、すべてのユーザーがアクセスできる単一のメソッドを含むセキュアな Jakarta Enterprise Beans。
  • 単一のメソッドが含まれる中間 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>

2.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 EAP『 How to Configure Server Security』の「 Create an Elytron Permission Mapper 」を参照してください。

以下のコマンドは、以下の設定を含む 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 パーミッションセットはすでにデフォルト設定に存在します。

承認の転送後にプリンシパルトランスフォーマーが使用される場合、これらのトランスフォーマーは認証と承認プリンシパルの両方に適用されます。

2.2.3. プリンシパルユーザー名のケース文字を変更する case-principal-transformer の作成

elytron サブシステムには、case-principal-transformer プリンシパルトランスフォーマーが含まれます。このプリンシパルトランスフォーマーを使用して、プリンシパルのユーザー名を大文字または小文字のいずれかに変更できます。

case-principal-transformer プリンシパルトランスフォーマーには、デフォルトで true に設定される 大文字属性が含まれます

case-principal-transformer のユースケースを示すには、認証メカニズムを使用してプリンシパルをセキュリティーレルムにマップすることを検討してください。レルムマッパーは、マップされたプリンシパルを操作してセキュリティーレルムを特定し、そのアイデンティティーの 1 つを読み込みます。認証メカニズムは、アイデンティティーをレルム後のマッピングステージと最終的なプリンシパル変換ステージに渡します。その後、認証メカニズムは認証目的で ID を検証します。case-principal-transformer プリンシパルトランスフォーマーを使用して、マップされたプリンシパルの文字ケース形式を変換できます。

この手順の例では、セキュリティードメインのコンテキストで case-principal-transformer を使用します。以下の認証ポリシーとプリンシパルトランスフォーマーをインラインで使用することもできます。

  • http-authentication-factory
  • sasl-authentication-factory
  • ssl-context
  • aggregate-realm

手順

  1. case-principal-transformerelytron サブシステムに追加し、ユーザー名の文字ケースを選択します。

    1. トランスフォーマーのユーザー名を大文字に変更するには、デフォルトの 大文字 属性値を変更しないでください。

      デフォルトの 大文字 属性設定で elytron サブシステムに追加された <transformer_name> の例:

      /subsystem=elytron/case-principal-transformer=<transformer_name>:add(upper-case="true")

      または、コマンド構文を省略して、デフォルトの 大文字 属性値を使用することができます。

      /subsystem=elytron/case-principal-transformer=<transformer_name>:add()
    2. トランスフォーマーのユーザー名を小文字に変更するには、大文字 属性を false に設定します。

      upper-case 属性が false に設定された状態で elytron サブシステムに追加された <transformer_name> の例:

      /subsystem=elytron/case-principal-transformer=<transformer_name>:add(upper-case="false")

  2. オプション: elytron サブシステムを使用してプリンシパルトランスフォーマーを設定します。以下の例は、elytron サブシステムによって提供されたデフォルトの ApplicationDomain 設定へのプリンシパルトランスフォーマーを設定しました。Elytron は、デフォルトの ApplicationDomain 設定を pre-realm-principal-transformer に適用します。

    /subsystem=elytron/security-domain=ApplicationDomain:write-attribute(name=pre-realm-principal-transformer,value=<transformer_name>)
    注記

    レルムマッパーによって識別された後、ApplicationDomain 設定を使用するように post-realm-principal-transformer を設定できます。

関連情報

2.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);
    }
}

2.2.5. セキュリティー アイデンティティーの伝搬をサポートするメカニズム

以下の SASL メカニズムは、セキュリティー アイデンティティーの伝搬に対応しています。

  • PLAIN
  • OAUTHBEARER
  • GSSAPI
  • GS2-KRB5

以下の HTTP メカニズムは、セキュリティーアイデンティティーの伝搬に対応しています。

  • FORM 1
  • BASIC
  • BEARER_TOKEN
  • SPNEGO

1 FORM 認証は、Web ブラウザーでは自動的に処理されません。このため、HA クラスターで実行するときに FORM 認証を使用する Web アプリケーションでアイデンティティー伝搬を使用することはできません。BASICSPNEGO などの他のメカニズムは、HA クラスター環境でのアイデンティティー伝搬に対応しています。

2.3. Elytron でのアイデンティティーの切り替え

2.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);

2.4. レガシーのコア管理認証によるユーザー認証

2.4.1. デフォルトのユーザー設定

JBoss EAP のすべての管理インターフェースはデフォルトでセキュアになります。また、ユーザーはローカルインターフェースとリモートインターフェースという 2 つの方法で管理インターフェースにアクセスできます。これらの認証メカニズムの基本は、JBoss EAP『Security Architecture 』の「 Default Security 」と「 JBoss 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. プロンプトが表示されたら、ユーザー名、パスワード、および任意のロールを入力します。変更は、セキュリティーレルムの各プロパティーファイルに書き込まれます。

2.4.2. LDAP での認証の追加

JBoss EAP は、LDAP 認証を使用した管理インターフェースのセキュア化にも対応しています。LDAP の基本と JBoss EAP での仕組みについては、『Red Hat JBoss Enterprise Application Platform 7 セキュリティーガイド』ガイドの「LDAP」、「LDAP と管理インターフェース https://access.redhat.com/documentation/en-us/red_hat_jboss_enterprise_application_platform/7.4/html-single/security_architecture/#using_ldap_with_the_management_interfaces の使用」、「LDAP と ManagementRealm の使用」を参照してください。LDAP 認証を使用して管理インターフェースをセキュアにする方法の詳細は、JBoss EAP『 How to Configure Identity Management Guide』の「Securing the Management Interfaces with LDAP 」を参照してください

2.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)

2.5. ロールベースのアクセス制御

ロールベースのアクセス制御の基本は、JBoss EAP『 Security Architecture 』ガイドの「 ロールベースのアクセス制御 」と 「管理インターフェースへの RBAC の追加 」で説明されています。

2.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>

2.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>

2.5.3. ロールの管理

RBAC (Role-Based Access Control) を有効にすると、管理ユーザーが許可されている内容は、ユーザーが割り当てられているロールによって決まります。JBoss EAP 7 は、ユーザーおよびグループメンバーシップの両方に基づた包含と除外のシステムを使用して、ユーザーが所属するロールを決定します。

ユーザーは、以下の場合にロールに割り当てられると見なされます。

  • ロールに含めるユーザーとして一覧表示される、または
  • ロールに含まれるように一覧表示されるグループのメンバー。

また、ユーザーが以下を実行しない場合、ユーザーはロールに割り当てられると見なされます。

  • ロールから除外するユーザーとして一覧、または
  • ロールから除外される一覧のグループのメンバーです。

除外は包含よりも優先されます。

ユーザーおよびグループのロール包含および除外の設定は、管理コンソールと管理 CLI の両方を使用して設定できます。

この設定を実行できるのは、SuperUser または Administrator ロールのユーザーのみです。

2.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
注記

除外の一覧からユーザーを削除しても、ユーザーはシステムから削除されません。また、そのロールが必ずそのユーザーに割り当てられるようになるわけではありません。依然としてロールはグループメンバーシップに基づいて除外される可能性があります。

2.5.4. Elytron サブシステムを使用したユーザーロール割り当ての設定

ロールの管理 セクションで説明しているように、ユーザーのロールマッピングを直接追加することに加え、elytron サブシステムによって提供されるアイデンティティーから直接取得されるように RBAC ロールを設定することもできます。

RBAC システムを設定して elytron サブシステムによって提供されるロールを使用するには、以下を実行します。

/core-service=management/access=authorization:write-attribute(name=use-identity-roles,value=true)
重要

この機能を使用するには RBAC が有効にされており、プリンシパルには RBAC ロールがなければなりません。

2.5.5. ロールおよびユーザーグループ

ユーザーグループは、1 人以上のユーザーに割り当てることのできる任意のラベルです。管理インターフェースを使用して認証を行う場合、管理インターフェースのセキュア化方法に応じて、ユーザーには elytron サブシステムまたはコア管理認証のいずれかからグループが割り当てられます。RBAC システムは、所属するユーザーグループに応じて、自動的にロールをユーザーに割り当てるように設定できます。また、グループメンバーシップに基づいてロールからユーザーを除外することもできます。

2.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
注記

除外の一覧からグループを削除しても、システムからそのグループは削除されません。また、ロールがグループのメンバーに割り当てられることを保証する訳ではありません。依然としてロールはグループメンバーシップに基づいて除外される可能性があります。

2.5.7. LDAP での RBAC の使用

LDAP で RBAC を使用する基本と、JBoss EAP が LDAP で RBAC を使用するように設定する方法は、JBoss EAP『 How to Configure Identity Management Guide』の「LDAP and RBAC 」セクションを参照してください

2.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 の部分のリソースが表示されないことを意味します。

2.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 を適切な情報に置き換えます。

重要

ユーザーまたはグループが割り当てられている場合、スコープ指定ロールは削除できません。最初にロールの割り当てを削除してから、スコープ指定ロールを削除します。

ユーザーの追加および削除

スコープ指定ロールへのユーザーの追加および削除は 標準ロールの追加と削除と同じプロセスに従います。

2.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. メンバーを含めるにはプラス (+) ボタンを選択し、メンバーを除外するにはマイナス (-) ボタンを選択します。

2.5.9. 制約の設定

2.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
        }
    }
}

ロールと、実行できる各操作は、属性の設定によって異なります。これは、以下の表で説明されています。

表2.2 機密性制約設定の結果

requires-readrequires-writerequires-addressable

true

読み取りは機密です。AuditorAdministratorSuperUser のみを読み取ることができます。

書き込みは機密です。Administrator および SuperUser のみが書き込み可能です。

アドレス指定は機密です。AuditorAdministratorSuperUser のみがアドレス指定できます。

false

読み取りは機密ではありません。すべての管理ユーザーが読み取り可能です。

書き込みは機密ではありません。Maintainer、 Administrator、および SuperUser のみが書き込み可能です。また、Deployer はリソースをアプリケーションリソースとして記述することもできます。

アドレス指定は機密ではありません。すべての管理ユーザーがアドレス指定できます。

2.5.9.2. 機密性制約の一覧

以下の管理 CLI コマンドを使用すると、利用可能な機密性制約のリストを JBoss EAP 管理モデルから直接確認できます。

/core-service=management/access=authorization/constraint=sensitivity-classification:read-resource(include-runtime=true,recursive=true)

2.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 ロールを作成することが推奨されます。

2.5.9.4. アプリケーションリソース制約の一覧表示

以下の管理 CLI コマンドを使用すると、利用可能なアプリケーションリソースのリストを JBoss EAP 管理モデルから直接確認できます。

/core-service=management/access=authorization/constraint=application-classification:read-resource(include-runtime=true,recursive=true)

2.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 式は、属性の設定に依存します。これは、以下の表で説明されています。

表2.3 Vault 式制約設定の結果

requires-readrequires-write

true

読み取り操作は機密です。AuditorAdministrator、および SuperUser のみを読み取ることができます。

書き込み操作は機密です。Administrator および SuperUser のみが書き込み可能です。

false

読み取り操作は機密ではありません。すべての管理ユーザーは読み取りが可能です。

書き込み操作は機密ではありません。MonitorAdministrator、および SuperUser は書き込み可能です。Deployer は、vault 式がアプリケーションリソースにある場合にも書き込み可能です。

第3章 認証情報のセキュアな保存

JBoss EAP では、設定ファイル外で機密文字列を暗号化できます。これらの文字列はキーストアに格納でき、その後アプリケーションおよび検証システムに対して復号化されます。機密文字列は以下のいずれかに格納できます。

  • クレデンシャルストア: JBoss EAP 7.1 で導入されるクレデンシャルストアは、ストレージファイルで暗号化することで、機密およびプレーンテキストの文字列を安全に保護できます。各 JBoss EAP サーバーに複数のクレデンシャルストアを含めることができます。
  • パスワード vault: レガシー設定で使用されると、パスワード vault は Java キーストアを使用して、設定ファイル外に機密文字列を保存します。各 JBoss EAP サーバーには単一のパスワード vault のみを含めることができます。

EAP_HOME/standalone/configuration/EAP_HOME/domain/configuration/ の設定ファイルは、すべてデフォルトでは読み取り可能です。プレーンテキストパスワードを設定ファイルに保存せず、クレデンシャルストアまたはパスワード vault のいずれかに認証情報を配置することを強く推奨します。

設定ファイルにプレーンテキストのパスワードを配置する場合、これらのファイルは、限られたユーザーのみがアクセスできるようにする必要があります。JBoss EAP 7 を実行しているユーザーアカウントには少なくとも読み書き込みアクセスが必要です。

3.1. クレデンシャルストア

elytron サブシステムで導入されたクレデンシャルストアは、セキュアなストレージおよび認証情報を使用できるようにします。クレデンシャルストアおよびその他の Elytron コンポーネントに関する背景情報は、『 セキュリティーアーキテクチャー 』ガイドの「 コアの概念およびコンポーネント 」を参照してください。

使用してパスワードやその他の機密文字列を保存するには、パスワード vault よりもクレデンシャルストアの使用が推奨されます。クレデンシャルストアを使用すると、外部ツールを使用せずに JBoss EAP 管理 CLI 内での認証情報の管理が容易になります。JBoss EAP サーバーごとに単一のパスワード vault という制限と比較すると、JBoss EAP サーバー内で複数のクレデンシャルストアを使用することもできます。

デフォルトのクレデンシャルストア実装は JCEKS キーストアファイルを使用して認証情報を保存します。新しいクレデンシャルストアを作成する場合、デフォルトの実装では、既存のキーストアファイルを参照したり、JBoss EAP で自動的に作成したりできます。現在、デフォルトの実装では、クリアテキストのパスワードのみを保存できます。

重要

elytron サブシステムは、ストレージと同じファイルを使用するためのチェックを複数のクレデンシャルストアに対して提供しません。複数のクレデンシャルストアに同じファイルを使用しないことを強く推奨します。また、リモートファイルシステムを使用してストレージファイルを共有することもお勧めします。

共有ストレージファイルを使用する必要がある場合は、アクセスしているクレデンシャルストアに read-only フラグを必ず設定してください。これにより、ファイルが変更されなくなります。ファイルを外部から更新した後は、変更された値を反映するために各クレデンシャルストアをリロードする必要があります。管理対象ドメインでクレデンシャルストアを使用する場合は、同様のプロセスを実行する必要があります。

クレデンシャルストアには機密情報が含まれるため、そのストアを含むディレクトリーには、一部のユーザーのみがアクセスできるようにする必要があります。JBoss EAP を実行しているユーザーアカウントには少なくとも読み書き込みアクセスが必要です。

重要

JBoss EAP はクレデンシャルストアファイルをメモリーに読み込み、変更を異なるタイミングで書き込みます。JBoss EAP プロセスを実行しているユーザーに、ストアファイルへのパーミッションが設定されるようにしてください。また、JBoss EAP の実行中にストアファイルを外部から変更しないようしてください。

ファイルが外部で変更されると、クレデンシャルストアで reload() 操作を使用して、JBoss EAP にストアファイルの内容を再ロードさせることができます。

3.1.1. クレデンシャルストアの作成

クレデンシャルストアを作成するには、新しいクレデンシャルストアファイルへのパスを定義し、クレデンシャルストアの暗号化に使用するマスターパスワードを指定する必要があります。このストアを含むディレクトリーは、一部のユーザーのみがアクセスできるようにする必要があります。JBoss EAP を実行しているユーザーアカウントには少なくとも読み書き込みアクセスが必要です。

重要

JCEKS キーストアの実装は Java ベンダーごとに異なります。そのため、JBoss EAP インスタンスは JCEKS キーストアを生成した同じベンダーから JDK を実行する必要があります。

その他の JBoss EAP 設定でパスを指定するのと同様に、relative-to 属性を使用して別のものに相対パスを指定することもできます。

スタンドアロンサーバーのクレデンシャルストアの作成

以下の管理 CLI コマンドを使用してクレデンシャルストアを作成します。

/subsystem=elytron/credential-store=<store_name>:add(location="<path_to_store_file>", credential-reference={clear-text=<store_password>},create=true)

たとえば、以下のコマンドでは my_store という名前の新規ストアを作成し、jboss.server.data.dir/cred_stores/my_store.jceks ファイルを作成します。

/subsystem=elytron/credential-store=my_store:add(location="cred_stores/my_store.jceks", relative-to=jboss.server.data.dir,  credential-reference={clear-text=<secret_store_password>},create=true)
注記

default 以外の実装を使用する場合は、クレデンシャルストアのタイプを明示的に定義できます。詳細は「using a custom credential store implementation」のセクションを参照してください。

管理対象ドメインでのクレデンシャルストアの作成

管理対象ドメインでクレデンシャルストアを作成できますが、最初に WildFly Elytron Tool を使用して認証情報でリソースを準備する必要があります。管理対象ドメインに複数のホストコントローラーが存在する場合は、以下のいずれかのオプションを選択する必要があります。

  • 各ホストコントローラーにクレデンシャルストアを作成します。
  • クレデンシャルストアをホストコントローラーから他のすべてのホストコントローラーにコピーします。
  • ストレージファイルを Network File System(NFS)に配置し、作成されたすべてのクレデンシャルストアリソースにファイルを使用します。

または、WildFly Elytron Tool を使用せずにホストコントローラーに認証情報を指定してクレデンシャルストアファイルを作成できます。

注記

各サーバーにクレデンシャルストアリソースを定義する必要はありません。リソースが作成されるものと同じプロファイルを実行している各サーバーには、クレデンシャルストアファイルが含まれます。ストレージファイルは、サーバーデータディレクトリー relative-to=jboss.server.data.dir にあります。

手順

  1. WildFly Elytron Tool を使用してクレデンシャルストアストレージファイルを作成します。詳細は、「WildFly Elytron Tool を使用した認証情報ストアのオフライン作成および修正」を参照してください。
  2. ストレージファイルを配布します。たとえば、scp を使用してファイルを各ホストコントローラーに配布するか、NFS に保存して、作成したすべてのクレデンシャルストアリソースに使用します。

    注記

    NFS に保存され、複数のホストコントローラーのリソースで使用されるクレデンシャルストアファイルについては、クレデンシャルストアを読み取り専用モードで使用し、一貫性を維持する必要があります。さらに、クレデンシャルストアファイルの絶対パスを指定します。

    /profile=<profile_name>/subsystem=elytron/credential-store=<store_name>:add(location=<absolute_path_to_store_keystore>,credential-reference={clear-text="<store_password>"},create=false,modifiable=false)
  3. オプション: クレデンシャルストアリソースをプロファイルで定義する必要がある場合は、ストレージファイルを使用してリソースを作成します。

    ストレージファイルからクレデンシャルストアリソースを作成する例。

    /profile=<profile_name>/subsystem=elytron/credential-store=<store_name>:add(location=<path_to_store_file>,credential-reference={clear-text="<store_password>"})

  4. オプション: ホストコントローラーの認証情報ストアリソースを作成します。

    ホストコントローラーのクレデンシャルストアリソースを作成する例。

    /host=<host_controller_name>/subsystem=elytron/credential-store=<store_name>:add(location=<path_to_store_file>,credential-reference={clear-text="<store_password>"})

3.1.2. 認証情報をクレデンシャルストアに追加する

新しい認証情報をクレデンシャルストアに追加するには、保存したい機密文字列にエイリアスを関連付けます。

注記

クレデンシャルストアのエイリアスは、デフォルトで大文字と小文字を区別しません。保存されたエイリアスは小文字で表示されます。また、大文字と小文字の組み合わせを使用して参照できます。

カスタムクレデンシャルストアを使用すると、ケースの機密性はカスタム実装によって決定されます。

以下の管理 CLI コマンドは認証情報をクレデンシャルストアに追加します。

/subsystem=elytron/credential-store=STORE_NAME:add-alias(alias=ALIAS, secret-value="SENSITIVE_STRING")

たとえば、エイリアス database-pw のあるパスワードを前のセクションで作成したストアに追加するには、以下を実行します。

/subsystem=elytron/credential-store=my_store:add-alias(alias=database-pw, secret-value="speci@l_db_pa$$_01")

管理対象ドメインのクレデンシャルストアに認証情報を追加する方法は、「 WildFly Elytron Tool を使用したクレデンシャルストアへの認証情報の追加 」を参照してください。

管理コンソールを使用した認証情報ストアエイリアスの編集
  1. 管理コンソールにログインし、Runtime タブをクリックします。
  2. サーバーを選択し、Security (Elytron)Stores の順に選択し、View をクリックします。
  3. クレデンシャルストアを選択し、Aliases をクリックしてエイリアスを編集します。

3.1.3. 設定で保存された認証情報の使用

クレデンシャルストアに保存されているパスワードまたは機密文字列を参照するには、JBoss EAP 設定で credential-reference 属性を使用します。credential-reference は、JBoss EAP 設定の全体でパスワードやその他の機密文字列を提供する代わりに使用できます。

credential-reference={store=STORE_NAME, alias=ALIAS}

たとえば、前のサンプルのクレデンシャルストアに追加されたパスワードを使用して新しいデータソースを作成する場合は、以下のように credential-reference を使用できます。

data-source add --name=my_DS --jndi-name=java:/my_DS --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=my_store, alias=database-pw}

上記の例では、--password を使用してパスワードを指定する代わりに、ストア名とエイリアスを含む credential-reference が指定されます。作成されたデータソース設定を確認すると、パスワードは定義されず、password が定義されておらず、credential-reference 属性が定義されることに注意してください。

/subsystem=datasources/data-source=my_DS:read-resource()
{
    "outcome" => "success",
    "result" => {
        ...
        "credential-reference" => {
            "store" => "my_store",
            "alias" => "database-pw"
        },
        ...
        "password" => undefined,
        ...
    }
}

3.1.4. クレデンシャルストアの認証情報の自動更新

クレデンシャルストアをお持ちの場合は、認証情報を参照する前に認証情報を追加したり、既存の認証情報を更新したりする必要はありません。Elytron はこのプロセスを自動化します。

認証情報参照を設定する場合は、store 属性と clear-text 属性の両方を指定します。Elytron は、store 属性によって指定されたクレデンシャルストアの認証情報を自動的に追加 または更新します。オプションで alias 属性を指定できます。

Elytron は以下のようにクレデンシャルストアを更新します。

  • エイリアスを指定する場合は、以下を行います。

    • エイリアスのエントリーが存在する場合は、既存の認証情報が指定のクリアテキストパスワードに置き換えられます。
    • エイリアスのエントリーが存在しない場合は、指定したエイリアスとクリアテキストパスワードを使用して、クレデンシャルストアに新しいエントリーが追加されます。
  • エイリアスを指定しない場合、Elytron はエイリアスを生成し、生成されたエイリアスと指定のクリアテキストパスワードを使用してクレデンシャルストアに新しいエントリーを追加します。

clear-text 属性は、クレデンシャルストアが更新されると管理モデルから削除されます。

以下の例は、store、clear -text、および alias 属性を指定する認証情報参照を作成する方法を示しています。

/subsystem=elytron/key-store=exampleKS:add(relative-to=jboss.server.config.dir, path=example.keystore, type=JCEKS, credential-reference={store=mycredstore, 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 属性によって指定されたクレデンシャルストアは変更されません。

3.1.5. クレデンシャルストアの認証情報のリスト

以下の管理 CLI コマンドを使用すると、クレデンシャルストアに含まれるすべての認証情報のエイリアスを一覧表示できます。

/subsystem=elytron/credential-store=STORE_NAME:read-aliases()

例を以下に示します。

/subsystem=elytron/credential-store=my_store:read-aliases()
{
    "outcome" => "success",
    "result" => [
        "database-pw"
    ]
}

3.1.6. クレデンシャルストアからの認証情報の削除

以下のコマンドを使用して、クレデンシャルストアから認証情報を削除できます。

/subsystem=elytron/credential-store=STORE_NAME:remove-alias(alias=ALIAS)

例を以下に示します。

/subsystem=elytron/credential-store=my_store:remove-alias(alias=database-pw)

3.1.7. 外部ソースからクレデンシャルストアのマスターパスワードの取得

クレデンシャルストアのマスターパスワードをクリアで指定する代わりに、擬似クレデンシャルストアを使用してパスワードを指定することもできます。以下のオプションを使用できます。

EXT

java.lang.Runtime#exec(java.lang.String) を使用した外部コマンド。パラメーターが必要な場合、それらは文字列のスペースで区切られたリストを使用して指定されます。外部コマンドは、オペレーティングシステムからの実行可能ファイル (シェルスクリプトや実行可能バイナリーなど) を参照します。パスワードは、実行したコマンドの標準出力から読み込まれます。

{EXT}/usr/bin/getTheMasterPasswordScript.sh par1 par2

CMD

java.lang.ProcessBuilder を使用した外部コマンドパラメーターが必要な場合、それらは文字列のカンマ区切られたリストを使用して指定されます。外部コマンドは、オペレーティングシステムからの実行可能ファイル (シェルスクリプトや実行可能バイナリーなど) を参照します。パスワードは、実行したコマンドの標準出力から読み込まれます。

{CMD}/usr/bin/getTheMasterPasswordScript.sh par1,par2

MASK

PBE または Password Based Encryption を使用してマスクされたパスワード。SALT および ITERATION の値が含まれる以下の形式である必要があります。

MASK-MASKED_VALUE;SALT;ITERATION

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=master-cred-store, alias=master-pw})

3.1.8. FIPS 140-2 対応クレデンシャルストアの定義

FIPS 140-2 準拠のクレデンシャルストアは、以下のいずれかの方法で定義できます。

3.1.8.1. NSS データベースを使用した FIPS 140-2 対応クレデンシャルストアの定義

FIPS に準拠するキーストアを取得するには、NSS データベースにアクセスする Sun PKCS#11 プロバイダーを使用します。データベースの定義方法には、「NSS データベースの設定」を参照してください。

  1. クレデンシャルストアで使用する秘密鍵を作成します。

    注記

    keytool コマンドが機能するには、nss_pkcsll_fips.cfg ファイルで nssDbMode 属性を readWrite の値に割り当てる必要があります。

    $ keytool -keystore NONE -storetype PKCS11 -storepass STORE_PASSWORD -genseckey -alias ALIAS -keyalg AES -keysize 256
  2. 外部クレデンシャルストアを作成します。外部クレデンシャルストアは PKCS#11 キーストアに秘密鍵を保持し、前の手順で定義したエイリアスを使用してこのキーストアにアクセスします。その後、このキーストアは JCEKS キーストアの認証情報を復号化するために使用されます。credential-store 属性に加え、credential-store KeyStoreCredentialStore 実装プロパティーは、外部クレデンシャルストアを設定するのに使用されます。

    /subsystem=elytron/credential-store=STORE_NAME:add(modifiable=true, implementation-properties={"keyStoreType"=>"PKCS11","external"=>"true","keyAlias"=>"ALIAS", externalPath="/path/to/EXTERNAL_STORAGE"},credential-reference={clear-text="STORE_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()

3.1.8.2. BouncyCastle プロバイダーを使用した FIPS 140-2 対応クレデンシャルストアの定義

以下の手順では、BouncyCastle プロバイダーを使用して FIPS 準拠のキーストアを取得する方法の概要を説明します。

  1. お使いの環境が BouncyCastle プロバイダーを使用するように設定されていることを確認します。
  2. クレデンシャルストアで使用する秘密鍵を作成します。

    $ keytool -genseckey -alias KEY_ALIAS -keyalg AES -keysize 128 -keystore KEYSTORE -storetype BCFKS -storepass PASSWORD -keypass PASSWORD
    重要

    FIPS クレデンシャルストアを elytron サブシステムで定義するには、キーストアの keypass および storepass が同じである必要があります。

  3. 外部クレデンシャルストアを作成します。外部クレデンシャルストアは BCFKS キーストアの秘密鍵を保持し、前の手順で定義したエイリアスを使用してこのキーストアにアクセスします。その後、このキーストアは JCEKS キーストアの認証情報を復号化するために使用されます。credential-store KeyStoreCredentialStore 実装プロパティーは、外部クレデンシャルストアを設定するために使用されます。

    /subsystem=elytron/credential-store=BCFKS_CREDENTIAL_STORE:add(relative-to=jboss.server.config.dir,credential-reference={clear-text=PASSWORD},implementation-properties={keyAlias=KEY_ALIAS,external=true,externalPath=CREDENTIAL_STORE,keyStoreType=BCFKS},create=true,location=KEYSTORE,modifiable=true)
  4. 作成後、クレデンシャルストアを使用して通常通りにエイリアスを保存することができます。

    /subsystem=elytron/credential-store=BCFKS_CREDENTIAL_STORE:add-alias(alias="ALIAS", secret-value="SENSITIVE_STRING")
  5. クレデンシャルストアから読み取り、エイリアスが正常に追加されたことを確認します。

    /subsystem=elytron/credential-store=BCFKS_CREDENTIAL_STORE:read-aliases()

3.1.9. クレデンシャルストアのカスタム実装の使用

クレデンシャルストアのカスタム実装を使用するには、以下を実行します。

  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)

3.1.10. WildFly Elytron Tool を使用した認証情報ストアのオフライン作成および修正

WildFly Elytron ツールは EAP_HOME/bin/ にある elytron-tool スクリプトを使用してアクセスします。このツールを使うことで、オフラインまたは停止された JBoss EAP サーバーのクレデンシャルストアを作成および変更できます。

重要

JCEKS キーストアの実装は Java ベンダーごとに異なります。そのため、JBoss EAP インスタンスは JCEKS キーストアを生成した同じベンダーから JDK を実行する必要があります。

重要

WildFly Elytron ツールを使用して、稼働中の JBoss EAP サーバーによって使用されているクレデンシャルストアを変更すると、ストアへの変更が失われる可能性があります。その代わりに、前述のセクションで説明されているように管理 CLI を使用して、稼働中のサーバーのクレデンシャルストアを作成し、変更する必要があります。

以下のコマンドは、Red Hat Enterprise Linux および Solaris システムで elytron-tool.sh を使用して示します。Windows Server システムの場合は、代わりに elytron-tool.bat スクリプトを使用してください。

WildFly Elytron ツールを使用したクレデンシャルストアの作成

以下のコマンドで、WildFly Elytron ツールを使用してクレデンシャルストアを作成します。

$ 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/my_store.jceks" --password supersecretstorepassword

コマンドでストアパスワードを指定しない場合は、その引数を省略し、標準入力を使用して手動でパスワードを入力するように求められます。ストアパスワードのには、Wi8ldFly Elytron ツールで生成された、マスクされたパスワードを使用することもできます。

WildFly Elytron Tool による BouncyCastle プロバイダーを使用した認証情報ストアの作成

以下の手順では、WildFly Elytron ツールを使用してクレデンシャルストアを作成する方法を説明します。

  1. 環境が BouncyCastle プロバイダーを使用するように設定されていることを確認します
  2. BCFKS キーストアを定義します。このキーストアがすでに存在する場合は、次のステップに進んでください。

    $ keytool -genkeypair -alias ALIAS -keyalg RSA -keysize 2048 -keypass PASSWORD -keystore KEYSTORE -storetype BCFKS -storepass PASSWORD
    重要

    FIPS クレデンシャルストアを elytron サブシステムで定義するには、キーストアの keypass および storepass が同じである必要があります。

  3. クレデンシャルストアの秘密鍵を生成します。

    $ keytool -genseckey -alias KEY_ALIAS -keyalg AES -keysize 128 -keystore KEYSTORE -storetype BCFKS -storepass PASSWORD -keypass PASSWORD
  4. 以下のコマンドで、WildFly Elytron ツールを使用してクレデンシャルストアを定義します。

    $ EAP_HOME/bin/elytron-tool.sh credential-store -c -a ALIAS -x ALIAS_PASSWORD -p PASSWORD -l KEYSTORE -u "keyStoreType=BCFKS;external=true;keyAlias=KEY_ALIAS;externalPath=CREDENTIAL_STORE"

WildFly Elytron Tool を使用したクレデンシャルストアへの認証情報の追加

以下のコマンドで、WildFly 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/my_store.jceks" --password supersecretstorepassword --add database-pw --secret speci@l_db_pa$$_01

クレデンシャルストアのパスワードを提供するのと同様に、コマンドでシークレットを指定しない場合は、この引数を省略できます。その場合、標準入力を使用してシークレットを手動で入力するように求められます。

WildFly Elytron Tool を使用したクレデンシャルストアのすべての認証情報の一覧表示

以下のコマンドで、WildFly Elytron ツールを使用してクレデンシャルストアの認証情報を一覧表示します。

$ 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/my_store.jceks" --password supersecretstorepassword --aliases

Wildfly Elytron Tool を使用した、認証情報ストアにエイリアスが存在するかどうかの確認

以下のコマンドで、WildFly Elytron ツールを使用してクレデンシャルストアにエリアスが存在するかどうかを確認します。

$ 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/my_store.jceks" --password supersecretstorepassword --exists database-pw

WildFly Elytron Tool を使用した認証情報ストアからの認証情報の削除

以下のコマンドで、WildFly Elytron ツールを使用してクレデンシャルストアから認証情報を削除します。

$ 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/my_store.jceks" --password supersecretstorepassword --remove database-pw

WildFly Elytron Tool で作成されたクレデンシャルストアを JBoss EAP サーバーに追加

WildFly Elytron ツールを使用してクレデンシャルストアを作成したら、以下の管理 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/my_store.jceks",credential-reference={clear-text=supersecretstorepassword})

クレデンシャルストアを JBoss EAP 設定に追加することで、credential-reference 属性を使用してクレデンシャルストアに保存されているパスワードまたは機密文字列を参照できます。

詳細は、EAP_HOME/bin/elytron-tool.sh credential-store --help コマンドを使用して、利用可能なオプションの詳細な一覧を表示してください。

3.1.10.1. 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 コマンドを使用して、利用可能なオプションの詳細な一覧を表示してください。

3.1.10.2. WildFly Elytron Tool を使用した、パスワード vault のクレデンシャルストアへの変換

WildFly Elytron ツールを使用することで、パスワード vault をクレデンシャルストアに変換できます。パスワード vault をクレデンシャルストアに変換するには、vault の初期化時に vault の値を使用する必要があります。

注記

パスワード vault を変換する際に、新しいクレデンシャルストアのエイリアスは、同等のパスワード vault ブロックおよび属性名 (VAULT_BLOCK::ATTRIBUTE_NAME) に基づいて、以下の形式で名前が付けられます。

シングルパスワード 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 の値が使用されます。

複数パスワード 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 コマンドを使用して、利用可能なオプションの詳細な一覧を表示してください。

3.1.11. 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
クレデンシャルストアに保存される機密文字列のクレデンシャル参照。

Elytron Client を使用したクライアント認証の設定に関する詳細は、JBoss EAP『 How to Configure Identity Management Guide』を参照してください

3.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 の例外が発生します。

3.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 -validity 730 -keystore EAP_HOME/vault/vault.keystore

    これにより、EAP_HOME/vault/vault.keystore ファイルに作成されたキーストアが作成されます。JBoss EAP では、パスワードなどの暗号化された文字列を保存するために使用されるエイリアス vault とともに単一のキーを保存します。

3.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-option name="ITERATION_COUNT" value="120"/>
  <vault-option name="ENC_FILE_DIR" value="EAP_HOME/vault/"/>
</vault><management> ...
********************************************

パスワード vault コマンドを対話的に実行するには、以下の手順が必要です。

  1. パスワード vault コマンドをインタラクティブに起動します。

    Red Hat Enterprise Linux または同様のオペレーティングシステムでは EAP_HOME/bin/vault.sh、Windows Server では EAP_HOME\bin\vault.bat を実行します。新しい対話セッションを開始するには、0 (ゼロ) と入力します。

  2. 要求パラメーターを入力します。

    プロンプトに従って必要なパラメーターを入力します。

  3. マスクされたパスワード情報をメモします。

    マスクされたパスワード、salt、iteration count (反復数) は、標準出力に出力されます。安全な場所にそれらを書き留めておきます。これらのエントリーは、パスワード Vault に追加する必要があります。キーストアファイルおよびこの値にアクセスすると、攻撃者はパスワード Vault の機密情報にアクセスできるようになります。

  4. 対話式コンソールを終了します。

    対話式コンソールを終了するには、2 と入力します。

例: 入出力

Please enter a Digit::   0: Start Interactive Session  1: Remove Interactive Session  2: Exit
0
Starting an interactive session
Enter directory to store encrypted files:EAP_HOME/vault/
Enter Keystore URL:EAP_HOME/vault/vault.keystore
Enter Keystore password: vault22
Enter Keystore password again: vault22
Values match
Enter 8 character salt:1234abcd
Enter iteration count as a number (Eg: 44):120
Enter Keystore Alias:vault
Initializing Vault
Nov 09, 2015 9:24:36 PM org.picketbox.plugins.vault.PicketBoxSecurityVault init
INFO: PBOX000361: Default Security Vault Implementation Initialized and Ready
Vault Configuration in AS7 config 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-option name="ITERATION_COUNT" value="120"/>
  <vault-option name="ENC_FILE_DIR" value="EAP_HOME/vault/"/>
</vault><management> ...
********************************************
Vault is initialized and ready for use
Handshake with Vault complete

+ キーストアパスワードは、設定ファイルおよびデプロイメントで使用するためにマスクされています。さらに、vault は初期化され、使用できる状態になります。

3.2.3. パスワード vault を使用する

パスワードやその他の機密属性をマスクして設定ファイルで使用できるようにするには、保存および復号化するパスワード vault を JBoss EAP 7 に認識させる必要があります。

以下のコマンドを使用して、JBoss EAP 7 がパスワード vault を使用するように設定できます。

/core-service=vault:add(vault-options=[("KEYSTORE_URL" => PATH_TO_KEYSTORE),("KEYSTORE_PASSWORD" => MASKED_PASSWORD),("KEYSTORE_ALIAS" => ALIAS),("SALT" => SALT),("ITERATION_COUNT" => ITERATION_COUNT),("ENC_FILE_DIR" => ENC_FILE_DIR)])

/core-service=vault:add(vault-options=[("KEYSTORE_URL" => "EAP_HOME/vault/vault.keystore"),("KEYSTORE_PASSWORD" => "MASK-5dOaAVafCSd"),("KEYSTORE_ALIAS" => "vault"),("SALT" => "1234abcd"),("ITERATION_COUNT" => "120"),("ENC_FILE_DIR" => "EAP_HOME/vault/")])
注記

Microsoft Windows Server を使用している場合は、バックスラッシュ (\\) を 1 つではなく 2 つ使用します。例: C:\\data\\vault\\vault.keystoreこれは、単一のバックスラッシュ (\) が文字エスケープに使用されるためです。

3.2.4. パスワード Vault に Sensitive 文字列を保存します。

プレーンテキストの設定ファイルにパスワードやその他の機密文字列を含めると、セキュリティーリスクが伴います。セキュリティ上の理由からも、これらの文字列はパスワード vault に保存します。パスワード vault では、これらの文字列は、マスク化した形式で設定ファイル、管理 CLI コマンド、およびアプリケーションで参照できます。

機密文字列は、ツールが各パラメーターの値を要求する場合には、パスワード Vault に対話形式で格納することができます。あるいは、コマンドラインですべてのパラメーターの値が提供される非対話形式で保存することもできます。各メソッドで同じ結果が表示されるため、どちらかを使用できます。これらのメソッドは、両者とも 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.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:24:36 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="../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-option name="ITERATION_COUNT" value="120"/>
  <vault-option name="ENC_FILE_DIR" value="../vault/"/>
</vault><management> ...
********************************************

vault スクリプトを呼び出した後、メッセージは標準出力に出力されます。このとき、vault ブロック、属性名、マスクされた文字列、設定で文字列を使用することについてのアドバイスが表示されます。この情報は、安全な場所にメモしておいてください。出力例を以下に示します。

Vault Block:vb
Attribute Name:password
Configuration should be done as follows:
VAULT::vb::password::1

パスワード vault コマンドを対話的に実行するには、以下の手順が必要です。

  1. パスワード vault コマンドをインタラクティブに起動します。

    オペレーティングシステムのコマンドラインインターフェースを起動し、EAP_HOME/bin/vault.sh (Red Hat Enterprise Linux および同様のオペレーティングシステム) または EAP_HOME\bin\vault.bat (Microsoft Windows Server 上) を実行します。新しい対話セッションを開始するには、0 (ゼロ) と入力します。

  2. 要求パラメーターを入力します。

    プロンプトに従って必要なパラメーターを入力します。これらの値は、パスワード vault の作成時に提供された値と一致している必要があります。

    注記

    キーストアパスワードは、マスク形式ではなく、プレーンテキスト形式で指定する必要があります。

  3. 機密文字列に関するパラメーター入力を行います。

    機密文字列の保存を開始する場合は 0 (ゼロ) を入力します。プロンプトに従って必要なパラメーターを入力します。

  4. マスクされた文字列についての情報を書き留めておきます。

    メッセージは標準出力に出力され、vault ブロック、属性名、マスクされた文字列、設定の文字列の使用に関するアドバイスが表示します。この情報は、安全な場所にメモしておいてください。出力例を以下に示します。

    Vault Block:ds_Example1
    Attribute Name:password
    Configuration should be done as follows:
    VAULT::ds_Example1::password::1
  5. 対話式コンソールを終了します。

    対話式コンソールを終了するには、2 と入力します。

例: 入出力

 =========================================================================
  JBoss Vault
  JBOSS_HOME: EAP_HOME
  JAVA: java
 =========================================================================
 **********************************
 ****  JBoss Vault  ***************
 **********************************
Please enter a Digit::   0: Start Interactive Session  1: Remove Interactive Session  2: Exit
0
Starting an interactive session
Enter directory to store encrypted files:EAP_HOME/vault/
Enter Keystore URL:EAP_HOME/vault/vault.keystore
Enter Keystore password:
Enter Keystore password again:
Values match
Enter 8 character salt:1234abcd
Enter iteration count as a number (Eg: 44):120
Enter Keystore Alias:vault
Initializing Vault
Nov 09, 2015 9:24:36 PM org.picketbox.plugins.vault.PicketBoxSecurityVault init
INFO: PBOX000361: Default Security Vault Implementation Initialized and Ready
Vault Configuration in AS7 config 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-option name="ITERATION_COUNT" value="120"/>
  <vault-option name="ENC_FILE_DIR" value="EAP_HOME/vault/"/>
</vault><management> ...
 ********************************************
Vault is initialized and ready for use
Handshake with Vault complete
Please enter a Digit::  0: Store a secured attribute  1: Check whether a secured attribute exists  2: Remove secured attribute  3: Exit
0
Task: Store a secured attribute
Please enter secured attribute value (such as password):
Please enter secured attribute value (such as password) again:
Values match
Enter Vault Block:ds_Example1
Enter Attribute Name:password
Secured attribute value has been stored in vault.
Please make note of the following:
 ********************************************
Vault Block:ds_Example1
Attribute Name:password
Configuration should be done as follows:
VAULT::ds_Example1::password::1
 ********************************************
Please enter a Digit::  0: Store a secured attribute  1: Check whether a secured attribute exists  2: Remove secured attribute  3: Exit

3.2.5. 暗号化した機密文字列を設定で使用

暗号化されている機密文字列は、マスクされた形式で設定ファイルまたは管理 CLI コマンド内で使用でき、式の指定も可能です。

特定のサブシステム内で式が許可されているかどうかを確認するには、そのサブシステムに対して以下の管理 CLI コマンドを実行します。

/subsystem=SUBSYSTEM:read-resource-description(recursive=true)

このコマンドの実行の出力から、expressions-allowed パラメーターの値を探します。true の場合は、このサブシステムの設定内で式を使用できます。

以下の構文を使用して、プレーンテキスト文字列をマスクされたフォームに置き換えます。

${VAULT::VAULT_BLOCK::ATTRIBUTE_NAME::MASKED_STRING}

例: マスクされたフォームでのパスワードを使用したデータソース定義

...
  <subsystem xmlns="urn:jboss:domain:datasources:5.0">
    <datasources>
      <datasource jndi-name="java:jboss/datasources/ExampleDS" enabled="true" use-java-context="true" pool-name="H2DS">
        <connection-url>jdbc:h2:mem:test;DB_CLOSE_DELAY=-1</connection-url>
        <driver>h2</driver>
        <pool></pool>
        <security>
          <user-name>sa</user-name>
          <password>${VAULT::ds_ExampleDS::password::1}</password>
        </security>
      </datasource>
      <drivers>
         <driver name="h2" module="com.h2database.h2">
            <xa-datasource-class>org.h2.jdbcx.JdbcDataSource</xa-datasource-class>
         </driver>
      </drivers>
    </datasources>
  </subsystem>
...

3.2.6. アプリケーションで暗号化した機密文字列の使用

パスワード vault に保存されている暗号化された文字列は、アプリケーションのソースコードで使用できます。以下の例は、サーブレットのソースコードの抜粋です。これは、プレーンテキストのパスワードではなく、データソース定義でのマスクされたパスワードの使用を示しています。プレーンテキストバージョンはコメントアウトされているため、違いがわかります。

例: vault 処理したパスワードを使用したサーブレット

@DataSourceDefinition(
        name = "java:jboss/datasources/LoginDS",
        user = "sa",
        password = "VAULT::DS::thePass::1",
        className = "org.h2.jdbcx.JdbcDataSource",
        url = "jdbc:h2:tcp://localhost/mem:test"
)
/*old (plaintext) definition
@DataSourceDefinition(
        name = "java:jboss/datasources/LoginDS",
        user = "sa",
        password = "sa",
        className = "org.h2.jdbcx.JdbcDataSource",
        url = "jdbc:h2:tcp://localhost/mem:test"
)*/

3.2.7. 機密文字列がパスワード vault 内にあるかどうかを確認します。

パスワード vault に機密文字列を保存または使用する前に、その文字列がすでに保存されているかどうかを確認すると便利です。

このチェックは、ユーザーに各パラメーターの値の入力を求める対話形式または、コマンドラインですべてのパラメーターの値が提供される非対話形式のいずれかで実行できます。各メソッドで同じ結果が表示されるため、どちらかを使用できます。これらのメソッドは、両者とも vault スクリプトで呼び出しされます。

非対話形式で、すべてのパラメーター値を一括で提供します。すべてのパラメーターの説明は、「パスワード vault の初期化」を参照してください。パスワード vault コマンドを非対話的に実行するには、EAP_HOME/bin/ にある vault スクリプトを、関連情報のパラメーターを使って呼び出します。

$ vault.sh --keystore KEYSTORE_URL --keystore-password KEYSTORE_PASSWORD --alias KEYSTORE_ALIAS --check-sec-attr --vault-block VAULT_BLOCK --attribute ATTRIBUTE --enc-dir ENC_FILE_DIR --iteration ITERATION_COUNT --salt SALT

プレースホルダーの値を実際の値に置き換えます。パラメーター KEYSTORE_URLKEYSTORE_PASSWORD、および KEYSTORE_ALIAS の値は、パスワード vault の作成時に提供された値と一致している必要があります。

注記

キーストアパスワードは、マスク形式ではなく、プレーンテキスト形式で指定する必要があります。

機密文字列が指定された vault ブロックに保存されると、以下のメッセージが表示されます。

Password already exists.

値が指定のブロックに保存されていない場合は、以下のメッセージが表示されます。

Password doesn't exist.

パスワード vault コマンドを対話的に実行するには、以下の手順が必要です。

  1. パスワード vault コマンドをインタラクティブに起動します。

    Red Hat Enterprise Linux または同様のオペレーティングシステムでは EAP_HOME/bin/vault.sh、Windows Server では EAP_HOME\bin\vault.bat を実行します。新しい対話セッションを開始するには、0 (ゼロ) と入力します。

  2. 要求パラメーターを入力します。プロンプトに従って必要な認証パラメーターを入力します。これらの値は、パスワード vault の作成時に提供された値と一致している必要があります。

    注記

    認証が求められたときは、キーストアパスワードはマスク形式ではなく、プレーンテキスト形式で指定する必要があります。

    • 1」を入力して セキュリティー保護された属性が存在するかどうかを確認します
    • 機密文字列を保存する vault ブロックの名前を入力します。
    • チェックする機密文字列の名前を入力します。

機密文字列が指定された vault ブロックに保存されている場合は、以下のような確認メッセージが表示されます。

A value exists for (VAULT_BLOCK, ATTRIBUTE)

機密文字列が指定ブロックに保存されていない場合は、以下のようなメッセージが出力されます。

No value has been store for (VAULT_BLOCK, ATTRIBUTE)

例: 対話式での機密文字列の確認

 =========================================================================
  JBoss Vault
  JBOSS_HOME: EAP_HOME
  JAVA: java
 =========================================================================
 **********************************
 ****  JBoss Vault  ***************
 **********************************
Please enter a Digit::   0: Start Interactive Session  1: Remove Interactive Session  2: Exit
0
Starting an interactive session
Enter directory to store encrypted files:EAP_HOME/vault
Enter Keystore URL:EAP_HOME/vault/vault.keystore
Enter Keystore password:
Enter Keystore password again:
Values match
Enter 8 character salt:1234abcd
Enter iteration count as a number (Eg: 44):120
Enter Keystore Alias:vault
Initializing Vault
Nov 09, 2015 9:24:36 PM org.picketbox.plugins.vault.PicketBoxSecurityVault init
INFO: PBOX000361: Default Security Vault Implementation Initialized and Ready
Vault Configuration in AS7 config 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-option name="ITERATION_COUNT" value="120"/>
  <vault-option name="ENC_FILE_DIR" value="EAP_HOME/vault/"/>
</vault><management> ...
 ********************************************
Vault is initialized and ready for use
Handshake with Vault complete
Please enter a Digit::  0: Store a secured attribute  1: Check whether a secured attribute exists  2: Remove secured attribute  3: Exit
1
Task: Verify whether a secured attribute exists
Enter Vault Block:vb
Enter Attribute Name:password
A value exists for (vb, password)
Please enter a Digit::  0: Store a secured attribute  1: Check whether a secured attribute exists  2: Remove secured attribute  3: Exit

3.2.8. パスワード vault からの機密文字列の削除

セキュリティー上の理由から、機密文字列が不要になった場合は、パスワード vault から削除することが推奨されます。たとえば、アプリケーションの使用を停止する場合、データソース定義で使用される機密文字列を同時に削除する必要があります。

重要

前提条件として、パスワード vault から機密文字列を削除するには、JBoss EAP の設定で使用されるかどうかを確認します。

この操作は、ユーザーに各パラメーターの値の入力を求める対話形式または、コマンドラインですべてのパラメーターの値が提供される非対話形式のいずれかで実行できます。各メソッドで同じ結果が表示されるため、どちらかを使用できます。これらのメソッドは、両者とも vault スクリプトで呼び出しされます。

非対話形式で、すべてのパラメーター値を一括で提供します。すべてのパラメーターの説明は、「パスワード vault の初期化」を参照してください。パスワード vault コマンドを非対話的に実行するには、EAP_HOME/bin/ にある vault スクリプトを、関連情報のパラメーターを使って呼び出します。

$ vault.sh --keystore KEYSTORE_URL --keystore-password KEYSTORE_PASSWORD --alias KEYSTORE_ALIAS --remove-sec-attr --vault-block VAULT_BLOCK --attribute ATTRIBUTE --enc-dir ENC_FILE_DIR --iteration ITERATION_COUNT --salt SALT

プレースホルダーの値を実際の値に置き換えます。パラメーター KEYSTORE_URLKEYSTORE_PASSWORD、および KEYSTORE_ALIAS の値は、パスワード vault の作成時に提供された値と一致している必要があります。

注記

キーストアパスワードは、マスク形式ではなく、プレーンテキスト形式で指定する必要があります。

機密文字列が正常に削除されると、以下のような確認メッセージが表示されます。

Secured attribute [VAULT_BLOCK::ATTRIBUTE] has been successfully removed from vault

機密文字列が削除されない場合は、以下のようなメッセージが表示されます。

Secured attribute [VAULT_BLOCK::ATTRIBUTE] was not removed from vault, check whether it exist

例: 出力

$ ./vault.sh --keystore EAP_HOME/vault/vault.keystore --keystore-password vault22 --alias vault --remove-sec-attr --vault-block vb --attribute password --enc-dir EAP_HOME/vault/ --iteration 120 --salt 1234abcd
 =========================================================================
  JBoss Vault
  JBOSS_HOME: EAP_HOME
  JAVA: java
 =========================================================================
Dec 23, 2015 1:54:24 PM org.picketbox.plugins.vault.PicketBoxSecurityVault init
INFO: PBOX000361: Default Security Vault Implementation Initialized and Ready
Secured attribute [vb::password] has been successfully removed from vault

対話式での機密文字列の削除

パスワード vault コマンドを対話的に実行するには、以下の手順が必要です。

  1. パスワード vault コマンドをインタラクティブに起動します。

    Red Hat Enterprise Linux または同様のオペレーティングシステムでは EAP_HOME/bin/vault.sh、Microsoft Windows Server では EAP_HOME\bin\vault.bat を実行します。新しい対話セッションを開始するには、0 (ゼロ) と入力します。

  2. 要求パラメーターを入力します。

    プロンプトに従って必要な認証パラメーターを入力します。これらの値は、パスワード vault の作成時に提供された値と一致している必要があります。

    注記

    認証が求められたときは、キーストアパスワードはマスク形式ではなく、プレーンテキスト形式で指定する必要があります。

    • 2 と入力して、セキュアな属性を削除するオプションを選択します。
    • 機密文字列を保存する vault ブロックの名前を入力します。
    • 削除する機密文字列の名前を入力します。

機密文字列が正常に削除されると、以下のような確認メッセージが表示されます。

Secured attribute [VAULT_BLOCK::ATTRIBUTE] has been successfully removed from vault

機密文字列が削除されない場合は、以下のようなメッセージが表示されます。

Secured attribute [VAULT_BLOCK::ATTRIBUTE] was not removed from vault, check whether it exist

例: 出力

 **********************************
 ****  JBoss Vault  ***************
 **********************************
Please enter a Digit::   0: Start Interactive Session  1: Remove Interactive Session  2: Exit
0
Starting an interactive session
Enter directory to store encrypted files:EAP_HOME/vault/
Enter Keystore URL:EAP_HOME/vault/vault.keystore
Enter Keystore password:
Enter Keystore password again:
Values match
Enter 8 character salt:1234abcd
Enter iteration count as a number (Eg: 44):120
Enter Keystore Alias:vault
Initializing Vault
Dec 23, 2014 1:40:56 PM org.picketbox.plugins.vault.PicketBoxSecurityVault init
INFO: PBOX000361: Default Security Vault Implementation Initialized and Ready
Vault Configuration in 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-option name="ITERATION_COUNT" value="120"/>
  <vault-option name="ENC_FILE_DIR" value="EAP_HOME/vault/"/>
</vault><management> ...
 ********************************************
Vault is initialized and ready for use
Handshake with Vault complete
Please enter a Digit::  0: Store a secured attribute  1: Check whether a secured attribute exists  2: Remove secured attribute  3: Exit
2
Task: Remove secured attribute
Enter Vault Block:vb
Enter Attribute Name:password
Secured attribute [vb::password] has been successfully removed from vault

3.2.9. Red Hat JBoss Enterprise Application Platform がパスワード vault のカスタム実装を使用するように設定する

指定したパスワード vault 実装を使用することに加え、SecurityVault のカスタム実装を使用することもできます。

重要

前提条件として、パスワード vault が初期化されていることを確認します。詳細は「パスワード vault の初期化」を参照してください。

パスワード vault にカスタム実装を使用するには、以下を実行します。

  1. インターフェース SecurityVault を実装するクラスを作成します。
  2. 直前の手順からクラスを含むモジュールを作成し、インターフェースが SecurityVault である org.picketbox で依存関係を指定します。
  3. 以下の属性で vault 要素を追加して、JBoss EAP 設定でカスタムパスワード vault を有効にします。

    • code: SecurityVault を実装するクラスの完全修飾名。
    • module: カスタムクラスが含まれるモジュールの名前。

オプションで、vault-options パラメーターを使用して、パスワード vault のカスタムクラスを初期化できます。

例: vault-options パラメーターを使用したカスタムクラスの使用

/core-service=vault:add(code="custom.vault.implementation.CustomSecurityVault", module="custom.vault.module", vault-options=[("KEYSTORE_URL" => PATH_TO_KEYSTORE),("KEYSTORE_PASSWORD" => MASKED_PASSWORD), ("KEYSTORE_ALIAS" => ALIAS),("SALT" => SALT),("ITERATION_COUNT" => ITERATION_COUNT),("ENC_FILE_DIR" => ENC_FILE_DIR)])

3.2.10. 外部ソースからのキーストアパスワードの取得

EXTEXTCCMD CMDC、または CLASS メソッドは、Java キーストアパスワードの取得について vault 設定で使用できます。

<vault-option name="KEYSTORE_PASSWORD" value="METHOD_TO_OBTAIN_PASSWORD"/>

この方法を以下で説明します。

{EXT}…​
これは、そのまま使えるコマンドを参照します。ここでの …​ は、実際のコマンドです。例: {EXT}/usr/bin/getmypassword --section 1 --query company/usr/bin/getmypassword コマンドを実行します。このコマンドは、標準出力にパスワードを表示し、セキュリティー vault のキーストアのパスワードとして使用します。この例では --section 1--query company のオプションを使用しています。
{EXTC[:expiration_in_millis]}…​
実際のコマンドを参照します。ここでの、... は、プラットフォームコマンドを実行するために Runtime.exec(String) メソッドに渡される、実際のコマンドラインです。コマンド出力の最初の行がパスワードとして使用されます。EXTC バリアントは expiration_in_millis ミリ秒のパスワードをキャッシュします。デフォルトのキャッシュの有効期限は 0 = infinity です。例: {EXTC:120000}/usr/bin/getmypassword --section 1 --query company は、キャッシュに /usr/bin/getmypassword が含まれるかどうかを検証します。出力が含まれる場合は、これを使用します。出力がない場合は、コマンドを実行してこれをキャッシュに出力して使用します。この例では、キャッシュの有効期限は 2 分 (120000 ミリ秒) です。
{CMD}…​ または {CMDC[:expiration_in_millis]}…​
一般的なコマンドは , (コンマ) で区切られた文字列です。最初の部分は実際のコマンドで、追加の部分はパラメーターを表します。コンマにバックスラッシュを付けることで、パラメーターの一部として維持することができます。例: {CMD}/usr/bin/getmypassword,--section,1,--query,company
{CLASS[@jboss_module_spec]}classname[:ctorargs]
[:ctorargs] は、クラス名から : (コロン) によって区切られるオプションの文字列です。これは、クラス名 ctor に渡されます。ctorargs は文字列のカンマ区切りの一覧です。例: {CLASS@org.test.passwd}org.test.passwd.ExternamPassworProviderこの例では、org.test.passwd.ExternamPassworProvider クラスが org.test.passwd モジュールからロードされ、toCharArray() メソッドを使用してパスワードを取得します。toCharArray() が利用できない場合は、toString() メソッドが使用されます。org.test.passwd.ExternamPassworProvider クラスにはデフォルトのコンストラクターが必要です。

第4章 Java Security Manager

4.1. Java Security Manager について

Java Security Manager は、Java Virtual Machine (JVM) サンドボックスの外部境界を管理するクラスで、JVM 内で実行されるコードが JVM 外のリソースと対話する方法を制御します。Java Security Manager を有効にすると、Java API はさまざまな潜在的に危険な操作を実行する前に、セキュリティーマネージャーで承認を確認します。Java Security Manager はセキュリティーポリシーを使用して、特定のアクションが許可または拒否されるかどうかを判断します。

4.2. Java セキュリティーポリシーの定義

Java セキュリティーポリシーは、さまざまなクラスのコードに対する定義されたパーミッションのセットです。Java Security Manager は、アプリケーションによって要求されたアクションをセキュリティーポリシーと比較します。ポリシーがアクションを許可した場合、Security Manager はそのアクションの実行を許可します。ポリシーによりアクションが許可されない場合、セキュリティーマネージャーはそのアクションを拒否します。

重要

以前のバージョンの JBoss EAP では、外部ファイル (例: EAP_HOME/bin/server.policy) を使用してポリシーが定義されていました。JBoss EAP 7 では、security-manager サブシステムと、個別のデプロイメントで XML ファイルを使用するという 2 つの方法で Java セキュリティーポリシーを定義します。Security-manager サブシステムは、ALL ディプロイメントの最小および最大パーミッションを定義します。一方、XML ファイルは、個別のディプロイメントによって要求されたパーミッションを指定します。

4.2.1. Security Manager サブシステムでのポリシーの定義

security-manager サブシステムを使用すると、すべてのデプロイメントの共有のパーミッションまたは共通のパーミッションを定義できます。これは、最小および最大のパーミッションセットを定義することで実行できます。すべてのデプロイメントには、最小パーミッションで定義された少なくともすべてのパーミッションが付与されます。このデプロイメントプロセスは、最大パーミッションセットで定義されたものを超えるパーミッションを要求すると失敗します。

例: 最小パーミッションセットを更新する管理 CLI コマンド

/subsystem=security-manager/deployment-permissions=default:write-attribute(name=minimum-permissions, value=[{class="java.util.PropertyPermission", actions="read", name="*"}])

例: 最大パーミッションセットを更新する管理 CLI コマンド

/subsystem=security-manager/deployment-permissions=default:write-attribute(name=maximum-permissions, value=[{class="java.util.PropertyPermission", actions="read,write", name="*"}, {class="java.io.FilePermission", actions="read,write", name="/-"}])

注記

最大パーミッションセットが定義されていない場合、その値のデフォルトが java.security.AllPermission に設定されます。

security-manager サブシステムの完全リファレンスは、JBoss EAP 『設定ガイド』を参照してください

4.2.2. デプロイメントでのポリシーの定義

JBoss EAP 7 では、JSR 342 に含まれ、Jakarta EE 仕様の一部である META-INF/permissions.xml をデプロイメントに追加できます。このファイルでは、デプロイメントに必要なパーミッションを指定できます。最低限のパーミッションセットが security-manager サブシステムに定義され、META-INF/permissions.xml がデプロイメントに追加されると、これらのパーミッションの結合が許可されます。permissions.xml で要求されるパーミッションが security-manager サブシステムで定義された最大ポリシーを超える場合、そのデプロイメントは成功しません。META-INF/permissions.xmlMETA-INF/jboss-permissions.xml の両方がデプロイメントにある場合は、META-INF/jboss-permissions.xml で要求されるパーミッションのみが付与されます。

この仕様は 、permission.xml がアプリケーション全体またはトップレベルのデプロイメントモジュールに対応するように指定します。サブデプロイメントに特定のパーミッションを定義する必要がある場合は、JBoss EAP 固有の META-INF/jboss-permissions.xml を使用できます。これは、permission.xml と同じ形式に従います。また、宣言されるデプロイメントモジュールにのみ適用されます。

例: permissions.xml のサンプル

<permissions version="7">
  <permission>
  <class-name>java.util.PropertyPermission</class-name>
  <name>*</name>
  <actions>read</actions>
  </permission>
</permissions>

4.2.3. モジュールにおけるポリシーの定義

<permissions> 要素を module.xml ファイルに追加してモジュールのパーミッションを制限できます。<permissions> 要素には、モジュールに付与するパーミッションを定義する、ゼロまたはそれ以上の <grant> 要素が含まれます。<grant> 要素には以下の属性が含まれます。

permission
付与するパーミッションの修飾クラス名。
name
パーミッションクラスのコンストラクターに提供するパーミッション名。
actions
一部のパーミッションタイプで必要なアクションの (オプション) リスト。

例: 定義されたポリシーを含む module.xml

<module xmlns="urn:jboss:module:1.5" name="org.jboss.test.example">
  <permissions>
    <grant permission="java.util.PropertyPermission" name="*" actions="read,write" />
    <grant permission="java.io.FilePermission" name="/etc/-" actions="read" />
  </permissions>
  ...
</module>

<permissions> 要素が存在する場合、モジュールはリストしたパーミッションのみに制限されます。<permissions> 要素が存在しない場合は、モジュールには制限がつきません。

4.3. Java Security Manager を使用した JBoss EAP の実行

重要

以前のバージョンの JBoss EAP では、-Djava.security.manager Java システムプロパティーとカスタムセキュリティーマネージャーの使用が許可されていました。これらのどちらも JBoss EAP 7 では対応していません。さらに、Java Security Manager のポリシーが security-manager サブシステム内で定義されるようになりました。つまり、外部ポリシーファイルと -Djava.security.policy Java システムプロパティーは JBoss EAP 7 ではサポートされません。

重要

Java Security Manager を有効にして JBoss EAP を起動する前に、すべてのセキュリティーポリシーが security-manager サブシステムで定義されていることを確認する必要があります。

Java Security Manager で JBoss EAP を実行するには、起動時に secmgr オプションを使用する必要があります。これには 2 つの方法があります。

  • 起動スクリプトでフラグを使用します。起動スクリプトで -secmgr フラグを使用するには、JBoss EAP インスタンスの起動時に、このフラグを含めます。

    例: 起動スクリプト

    ./standalone.sh -secmgr

  • 起動設定ファイルの使用

    重要

    設定ファイルを編集する前に、ドメインまたはスタンドアロンサーバーを完全に停止する必要があります。

    注記

    管理対象ドメインで JBoss EAP を使用している場合は、ドメインの各物理ホストまたはインスタンスで以下の手順を実行する必要があります。

    起動設定ファイルを使用して Java Security Manager を有効にするには、スタンドアロンインスタンスまたは管理対象ドメインのいずれかを実行しているかに応じて、standalone.conf または domain.conf ファイルのいずれかを編集する必要があります。Windows で実行している場合は、代わりに standalone.conf.bat または domain.conf.bat ファイルが使用されます。

    設定ファイルの secmgr="true" 行のコメントを解除します。

    例: standalone.conf または domain.conf

    # Uncomment this to run with a security manager enabled
    SECMGR="true"

    例: standalone.conf.bat または domain.conf.bat

    rem # Uncomment this to run with a security manager enabled
    set "SECMGR=true"

4.4. 以前のバージョンからの移行に関する考慮事項

Java Security Manager を有効にして実行してい状態で、JBoss EAP の以前のバージョンから JBoss EAP 7 へアプリケーションを移動する場合は、ポリシーの定義方法と JBoss EAP 設定およびデプロイメントの両方に必要な設定における変更に注意してください。

4.4.1. ポリシーの定義

以前のリリースの JBoss EAP では、ポリシーは外部設定ファイルで定義されていました。JBoss EAP 7 では、ポリシーは security-manager サブシステムを使用して定義されます。また、デプロイメントに含まれる permissions.xml または jboss-permissions.xml で定義されます。両方を使用してポリシーを定義する方法の詳細は、前のセクションで説明しています。

4.4.2. JBoss EAP 設定の変更

これまでのバージョンの JBoss EAP では、JBoss EAP の起動中に -Djava.security.manager および -Djava.security.policy Java システムプロパティーを使用できました。これらはサポート外となりました。代わりに secmgr フラグを使用して JBoss EAP が Java Security Manager で実行できるようにする必要があります。secmgr フラグの詳細は、前のセクションで説明しています。

4.4.3. カスタムセキュリティーマネージャー

JBoss EAP 7 では、カスタムセキュリティーマネージャーはサポートされません。

付録A リファレンス資料

A.1. Elytron サブシステムのコンポーネントのリファレンス

表A.1 add-prefix-role-mapper 属性

属性説明

prefix

各ロールに追加するプレフィックス。

表A.2 add-suffix-role-mapper 属性

属性説明

suffix

各ロールに追加するサフィックス。

表A.3 aggregate-http-server-mechanism-factory 属性

属性説明

http-server-mechanism-factories

集約する HTTP サーバーファクトリーの一覧。

表A.4 aggregate-principal-decoder 属性

属性説明

principal-decoders

集約するプリンシパルデコーダーの一覧。

表A.5 aggregate-principal-transformer 属性

属性説明

principal-transformers

集約するプリンシパルトランスフォーマーの一覧。

表A.6 aggregate-providers 属性

属性説明

providers

集約する参照 Provider[] リソースの一覧。

表A.7 aggregate-realm 属性

属性説明

authentication-realm

認証手順に使用するセキュリティーレルムへの参照。これは、認証情報の取得または検証に使用されます。

authorization-realm

承認手順のアイデンティティーの読み込みに使用するセキュリティーレルムへの参照。

authorization-realms

承認手順のアイデンティティーを読み込むために集約するセキュリティーレルムへの参照。

複数の承認レルムの使用方法は、『 How to Configure Identity Management』ガイドの「Configure Authentication and Authorization Using Multiple Identity Stores 」を参照してください。

注記

authorization-realmauthorization-realms 属性は互いに排他的なものです。レルムでは、2 つの属性いずれかのみを定義します。

表A.8 aggregate-role-mapper 属性

属性説明

role-mappers

集約するロールマッパーの一覧。

表A.9 aggregate-sasl-server-factory 属性

属性説明

sasl-server-factories

集約する SASL サーバーファクトリーの一覧。

表A.10 authentication-configuration 属性

属性説明

anonymous

true の場合は、匿名認証が許可されます。デフォルトは false です。

authentication-name

使用する認証名。

authorization-name

使用する認証名。

credential-reference

認証に使用する認証情報。これはクリアテキストで、または credential-store に保存されている認証情報への参照として指定できます。

extends

拡張する既存の認証設定。

host

使用するホスト。

kerberos-security-factory

GSS kerberos 認証情報の取得に使用される kerberos セキュリティーファクトリーへの参照。

mechanism-properties

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

port

使用するポート。

protocol

使用するプロトコル。

realm

使用するレルム。

sasl-mechanism-selector

SASL メカニズムセレクター文字列。使用方法は、「sasl-mechanism-selector Gammar」を参照してください。

security-domain

転送されたアイデンティティーを取得するためのセキュリティードメインへの参照。

表A.11 authentication-context 属性

属性説明

extends

拡張する既存の認証コンテキスト。

match-rules

この認証コンテキストに対して照合するルール。

表A.12 authentication-context match-rules 属性

属性説明

match-abstract-type

照合する抽象型。

match-abstract-type-authority

照合する抽象型の認証局。

match-host

照合するホスト。

match-local-security-domain

照合するローカルセキュリティードメイン。

match-no-user

true の場合、ルールはユーザーを照合しません。

match-path

照合するパッチ。

match-port

照合するポート。

match-protocol

照合するプロトコル。

match-urn

照合する URN。

match-user

照合するユーザー。

authentication-configuration

一致が成功した場合に使用する認証設定への参照。

ssl-context

正常な一致に使用する ssl-context への参照。

表A.13 caching-realm 属性

属性説明

maximum-age

項目がキャッシュ内に留まることができる時間 (ミリ秒単位)。-1 の値では、無制限で項目を維持します。デフォルトは -1 です。

maximum-entries

キャッシュに保持するエントリーの最大数。デフォルトは 16 です。

realm

jdbc-realmldap-realmfilesystem-realm またはカスタマーセキュリティレリムなどのキャッシュ可能なセキュリティレリムへの参照。

表A.14 certificate-authority-account 属性

属性説明

alias

キーストアの証明書の認証局アカウントキーのエイリアス。エイリアスがキーストアに存在しない場合は、認証局アカウントキーが自動的に生成され、エイリアスの下に PrivateKeyEntry として保存されます。

certificate-authority

使用する認証局の名前。デフォルトおよび唯一許可される値は LetsEncrypt です。

contact-urls

認証局がこのアカウントに関連する問題について連絡できる URL の一覧。

credential-reference

認証局アカウントキーにアクセスする際に使用される認証情報。

key-store

認証局アカウントキーが含まれるキーストア。

表A.15 chained-principal-transformer 属性

属性説明

principal-transformers

チェーンするプリンシパルトランスフォーマーの一覧。

表A.16 client-ssl-context 属性

属性説明

cipher-suite-filter

有効な暗号スイートを指定するために適用するフィルター。このフィルターは、コロン、コンマ、またはスペースで区切られた項目の一覧を取得します。各項目は、OpenSSL 形式の暗号スイート名、標準の SSL/TLS 暗号スイート名、または TLSv1.2DES などのキーワードになります。キーワードの詳細な一覧およびフィルター作成の詳細は、『CipherSuiteSelector』の Javadoc で掲載されています。デフォルト値は DEFAULT で、NULL 暗号化のない既知の暗号スイートすべてに対応し、認証のない暗号スイートを除外します。

key-manager

SSLContext 内で使用する key-manager への参照。

プロトコル

有効なプロトコル。許可されるオプション: SSLv2SSLv3TLSv1TLSv1.1TLSv1.2TLSv1.3これは、デフォルトで TLSv1TLSv1.1TLSv1.2、および TLSv1.3 を有効にするように設定されています。

警告

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

provider-name

使用するプロバイダーの名前。指定されていない場合は、プロバイダーからのプロバイダーはすべて SSLContext に渡されます。

providers

SSLContext の読み込みに使用する Provider[] を取得するプロバイダーの名前。

session-timeout

SSL セッションのタイムアウト。

trust-manager

SSLContext 内で使用する trust-manager への参照。

表A.17 concatenating-principal-decoder 属性

属性説明

joiner

principal-decoders 属性の値を結合するのに使用される文字列。

principal-decoders

連結するプリンシパルデコーダーの一覧。

表A.18 configurable-http-server-mechanism-factory 属性

属性説明

filters

名前に基づいてメカニズムを有効または無効にするために適用するフィルターの一覧。

http-server-mechanism-factory

ラップする http サーバーファクトリーへの参照。

properties

HTTP サーバーファクトリー呼び出しに渡されるカスタムプロパティー。

表A.19 configurable-http-server-mechanism-factory フィルター属性

属性説明

pattern-filter

正規表現パターンに基づいたフィルター

有効化

true の場合は、メカニズムが一致するとフィルターが有効になります。デフォルトは true です。

表A.20 configurable-sasl-server-factory 属性

属性説明

filters

順番に評価し、or を使用して組み合わせるフィルターの一覧。

properties

SASL サーバーファクトリー呼び出しに渡されるカスタムプロパティー。

protocol

メカニズムの作成時にファクトリーに渡されるプロトコル。

sasl-server-factory

ラップされる SASL サーバーファクトリーへの参照。

server-name

メカニズムの作成時にファクトリーに渡されるサーバー名。

表A.21 configurable-sasl-server-factory フィルター属性

属性説明

predefined-filter

メカニズム名をフィルターするために使用する事前定義フィルター。使用できる値は、HASH_MD5HASH_SHAHASH_SHA_256HASH_SHA_384HASH_SHA_512GS2SCRAMDIGESTIEC_ISO_9798EAPMUTUALBINDINGRECOMMENDED です。

pattern-filter

正規表現に基づくメカニズム名のフィルター。

有効化

true の場合は、ファクトリーが一致するとフィルターが有効になります。デフォルトは true です。

表A.22 constant-permission-mapper 属性

属性説明

permission-sets

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

permission-set は以下の属性を取ることができます。

  • permission-set

    パーミッションセットへの参照。

注記

permissions 属性は非推奨となり、permission-sets に置き換えられました。

表A.23 constant-principal-decoder 属性

属性説明

constant

プリンシパルデコーダーが常に返す定数値。

表A.24 constant-principal-transformer 属性

属性説明

constant

このプリンシパルトランスフォーマーが常に返す定数値。

表A.25 constant-realm-mapper 属性

属性説明

realm-name

返されるレルムへの参照。

表A.26 case-principal-transformer 属性

属性説明

upper-case

true (true)に設定されている場合にプリンシパルトランスフォーマーの名前を大文字に変換する任意の属性。これはデフォルト設定です。プリンシパルトランスフォーマーの名前を小文字に変換するには、属性を false に設定します。

表A.27 constant-role-mapper 属性

属性説明

roles

返されるロールの一覧です。

表A.28 credential-store 属性

属性説明

create

認証情報ストアが存在しない場合に、ストレージを作成するかどうかを指定します。

credential-reference

保護パラメーターの作成に使用される認証情報への参照。これはクリアテキストで、または credential-store に保存されている認証情報への参照として指定できます。

implementation-properties

クレデンシャルストアの実装固有のプロパティーのマッピング。

location

クレデンシャルストアストレージのファイル名。

modifiable

クレデンシャルストアが変更可能であるかどうか。

other-providers

クレデンシャルストア内で必要な Jakarta Connectors オブジェクトを作成できるプロバイダーを検索するプロバイダーの名前。これはキーストアベースのクレデンシャルストアにのみ有効です。これが指定されていない場合は、代わりにプロバイダーのグローバル一覧が使用されます。

provider-name

CredentialStoreSpi をインスタンス化するために使用するプロバイダーの名前。プロバイダーが指定されていない場合は、指定したタイプのインスタンスを作成できる、見つかった最初のプロバイダーが使用されます。

providers

必要なクレデンシャルストアタイプを作成できるプロバイダーを検索するプロバイダーの名前。これが指定されていない場合は、代わりにプロバイダーのグローバル一覧が使用されます。

relative-to

このクレデンシャルストアパスが相対するベースパス。

type

クレデンシャルストアのタイプ (例: KeyStoreCredentialStore )

表A.29 credential-store エイリアス

属性説明

entry-type

クレデンシャルストアに保存された認証情報エントリーのタイプ。

secret-value

パスワードなどのシークレット値。

表A.30 credential-store KeyStoreCredentialStore 実装プロパティー

属性説明

cryptoAlg

外部ストレージでのエントリーの暗号化と複合化に使用される暗号化アルゴリズム名。この属性は、external が有効な場合にのみ有効です。デフォルトは AES です。

external

データが外部ストレージに保存され、keyAlias によって暗号化されるかどうか。デフォルトは false です。

externalPath

外部ストレージへのパスを指定します。この属性は、external が有効な場合にのみ有効です。

keyAlias

外部ストレージへのデータの暗号化または復号化に使用されるクレデンシャルストア内のシークレットキーエイリアス。

keyStoreType

PKCS11 など、キーストアタイプデフォルトは KeyStore.getDefaultType() です。

表A.31 custom-credential-security-factory 属性

属性説明

configuration

カスタムセキュリティーファクトリーのオプションのキーおよび値設定。

class-name

カスタムセキュリティーファクトリーの実装のクラス名。

module

カスタムセキュリティーファクトリーのロードに使用するモジュール。

表A.32 custom-modifiable-realm 属性

属性説明

configuration

カスタムレルムのオプションのキーおよび値設定。

class-name

カスタムレルムの実装のクラス名。

module

カスタムレルムのロードに使用するモジュール。

表A.33 custom-permission-mapper 属性

属性説明

configuration

パーミッションマッパーのオプションのキーおよび値設定。

class-name

パーミッションマッパーの完全修飾クラス名。

module

パーミッションマッパーのロードに使用するモジュールの名前。

表A.34 custom-principal-decoder 属性

属性説明

configuration

プリンシパルデコーダーのオプションのキーおよび値設定。

class-name

プリンシパルデコーダーの完全修飾クラス名。

module

プリンシパルデコーダーのロードに使用するモジュールの名前。

表A.35 custom-principal-transformer 属性

属性説明

configuration

プリンシパルトランスフォーマーのオプションのキーおよび値設定。

class-name

プリンシパルトランスフォーマーの完全修飾クラス名。

module

プリンシパルトランスフォーマーのロードに使用するモジュールの名前。

表A.36 custom-realm 属性

属性説明

configuration

カスタムレルムのオプションのキーおよび値設定。

class-name

カスタムレルムの完全修飾クラス名。

module

カスタムレルムのロードに使用するモジュールの名前。

表A.37 custom-realm-mapper 属性

属性説明

configuration

レルムマッパーのオプションのキーおよび値設定。

class-name

レルムマッパーの完全修飾クラス名。

module

レルムマッパーのロードに使用するモジュールの名前。

表A.38 custom-role-decoder 属性

属性説明

configuration

ロールデコーダーのオプションのキーおよび値設定。

class-name

ロールデコーダーの完全修飾クラス名。

module

ロールデコーダーのロードに使用するモジュールの名前。

表A.39 custom-role-mapper 属性

属性説明

configuration

ロールマッパーのオプションのキーおよび値設定。

class-name

ロールマッパーの完全修飾クラス名。

module

ロールマッパーのロードに使用するモジュールの名前。

表A.40 dir-context 属性

属性説明

authentication-context

LDAP サーバーに接続するためのログイン認証情報を取得する認証コンテキスト。authentication-levelnone の場合は省略できます。これは、匿名認証に相当します。

authentication-level

使用する認証レベル (セキュリティーレベルまたは認証メカニズム)SECURITY_AUTHENTICATION または java.naming.security.authentication 環境プロパティーに対応します。許可される値は nonesimple、および sasl_mech 形式です。sasl_mech 形式は、SASL メカニズム名のスペース区切りリストです。

connection-timeout

LDAP サーバーへの接続のタイムアウト (ミリ秒単位)。

credential-reference

LDAP サーバーを認証し、接続するクレデンシャル参照。これは、authentication-levelnone の場合は省略できます。これは、匿名認証に相当します。

enable-connection-pooling

true 接続プールが有効になっている場合。デフォルトは false です。

module

クラスローディングベースとして使用されるモジュールの名前。

principal

LDAP サーバーを認証し、接続するプリンシパル。これは、authentication-levelnone の場合は省略できます。これは、匿名認証に相当します。

properties

DirContext の追加接続プロパティー。

read-timeout

LDAP 操作の読み取りタイムアウト (ミリ秒単位)。

referral-mode

照会に従う必要があるかどうかを判断するために使用されるモード。使用できる値は FOLLOWIGNORE、および THROW です。デフォルトは IGNORE です。

ssl-context

LDAP サーバーへの接続をセキュア化するために使用される SSL コンテキストの名前。

url

接続 URL

表A.41 filesystem-realm 属性

属性説明

encoded

アイデンティティー名がファイル名でエンコードされて (Base32) 保存されるべきかどうか。

レベル

適用するディレクトリーハッシュのレベルの数。デフォルト値は 2 です。

path

レルムを含むファイルへのパス。

relative-to

path で使用する事前に定義された相対パス。例: jboss.server.config.dir

表A.42 filtering-key-store 属性

属性説明

alias-filter

key-store から返されたエイリアスに適用するフィルター。返すエイリアスのコンマ区切りの一覧、または以下の形式のいずれかを指定できます。

  • ALL:-alias1:-alias2
  • NONE:+alias1:+alias2
注記

alias-filter 属性は、大文字と小文字を区別します。elytronAppServer などの大文字・小文字を合わせたエイリアスまたは大文字のエイリアスの使用は一部のキーストアプロバイダーで認識されない可能性があるため、elytronappserver などの小文字のエイリアスを使用することが推奨されます。

key-store

フィルター処理する key-store への参照。

表A.43 http-authentication-factory 属性

属性説明

http-server-mechanism-factory

このリソースに関連付ける HttpServerAuthenticationMechanismFactory

mechanism-configurations

メカニズム固有の設定のリスト。

security-domain

このリソースに関連付けるセキュリティードメイン。

表A.44 http-authentication-factory mechanism-configurations 属性

属性説明

credential-security-factory

メカニズムで必要な認証情報の取得に使用するセキュリティーファクトリー。

final-principal-transformer

このメカニズムレルムに適用する最終のプリンシパルトランスフォーマー。

host-name

この設定が適用されるホスト名。

mechanism-name

この設定は、名前を指定したメカニズムが使用される場合にのみ適用されます。この属性を省略すると、メカニズム名に一致します。

mechanism-realm-configurations

メカニズムが理解するレルム名の定義の一覧です。

pre-realm-principal-transformer

レルムが選択される前に適用するプリンシパルトランスフォーマー。

post-realm-principal-transformer

レルムの選択後に適用するプリンシパルトランスフォーマー。

protocol

この設定が適用されるプロトコル。

realm-mapper

メカニズムによって使用されるレルムマッパー。

表A.45 http-authentication-factory mechanism-configurations mechanism-realm-configurations 属性

属性説明

final-principal-transformer

このメカニズムレルムに適用する最終のプリンシパルトランスフォーマー。

post-realm-principal-transformer

レルムの選択後に適用するプリンシパルトランスフォーマー。

pre-realm-principal-transformer

レルムが選択される前に適用するプリンシパルトランスフォーマー。

realm-mapper

メカニズムによって使用されるレルムマッパー。

realm-name

メカニズムにより提示されるレルムの名前。

表A.46 identity-realm 属性

属性説明

attribute-name

このアイデンティティーに関連付けられた属性の名前。

attribute-values

Identity 属性に関連付けられた値の一覧。

identity

セキュリティーレルムから利用可能なアイデンティティー。

表A.47 jaspi-configuration 属性

属性説明

name

管理モデルでリソースを参照できる名前。

layer

この設定を AuthConfigFactoryに登録する際に使用されます。ワイルドカードの一致を許可するために省略できます。

application-context

この設定を AuthConfigFactory に登録する際に使用されます。ワイルドカードの一致を許可するために省略できます。

description

AuthConfigFactory に説明を加えるために使用されます。

表A.48 jaSPI-configuration server-auth-module 属性

属性説明

class-name

ServerAuthModule の完全修飾クラス名。

module

ServerAuthModule をロードするモジュール。

flag

このモジュールが他のモジュールに関連してどのように動作するかを示す制御フラグ。

options

初期化の際に ServerAuthModule に渡される設定オプション。

表A.49 jdbc-realm 属性

属性説明

principal-query

特定の鍵タイプに基づいてユーザーを認証するために使用される認証クエリーの一覧。

表A.50 jdbc-realm principal-query 属性

属性説明

attribute-mapping

このリソースに定義された属性マッピングのリスト。

bcrypt-mapper

SQL クエリーから返されるコラムを Bcrypt キータイプにマッピングするキーマッパー。

clear-password-mapper

SQL クエリーから返されるこらコラムをクリアパスワードキータイプにマッピングするキーマッパー。これには、ユーザーのパスワードを表す認証クエリーからのコラムインデックスである password-index 子要素があります。

data-source

データベースに接続するために使用されるデータソースの名前。

salted-simple-digest-mapper

SQL クエリーから返されたコラムを Simple Digest キータイプにマッピングするキーマッパー。

scram-mapper

SQL クエリーから返されるコラムを SCRAM キータイプにマッピングするキーマッパー。

simple-digest-mapper

SQL クエリーから返されたコラムを Simple Digest キータイプにマッピングするキーマッパー。

sql

特定のユーザーのテーブル列としてキーを取得し、そのタイプに応じてキーをマッピングするために使用される SQL ステートメント。

表A.51 jdbc-realm principal-query attribute-mapping 属性

属性説明

index

マッピングされた属性を表すクエリーからのコラムインデックス。

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

SQL クエリーから返されるコラムからマッピングされたアイデンティティー属性の名前。

表A.52 jdbc-realm principal-query bcrypt-mapper 属性

属性説明

iteration-count-index

パスワードの iteration count (反復回数) (サポートされている場合) を表す認証クエリーからの列インデックス。

password-index

ユーザーのパスワードを表す認証クエリーからのコラムインデックス。

salt-index

パスワードの salt (サポートされている場合) を表す認証クエリーからのコラムインデックス。

表A.53 jdbc-realm principal-query salted-simple-digest-mapper 属性

属性説明

algorithm

特定のパスワードキーマッパーのアルゴリズム。利用できる値は、password-salt-digest-md5password-salt-digest-sha-1password-salt-digest-sha-256password-salt-digest-sha-384password-salt-digest-sha-512salt-password-digest-md5salt-password-digest-sha-1salt-password-digest-sha-256salt-password-digest-sha-384salt-password-digest-sha-512 です。デフォルトは password-salt-digest-md5 です。

password-index

ユーザーのパスワードを表す認証クエリーからのコラムインデックス。

salt-index

パスワードの salt (サポートされている場合) を表す認証クエリーからのコラムインデックス。

表A.54 jdbc-realm principal-query simple-digest-mapper 属性

属性説明

algorithm

特定のパスワードキーマッパーのアルゴリズム。利用できる値は、simple-digest-md2simple-digest-md5simple-digest-sha-1simple-digest-sha-256simple-digest-sha-384simple-digest-sha-512 です。デフォルトは simple-digest-md5 です。

password-index

ユーザーのパスワードを表す認証クエリーからのコラムインデックス。

表A.55 jdbc-realm principal-query scram-mapper 属性

属性説明

algorithm

特定のパスワードキーマッパーのアルゴリズム。使用できる値は scram-sha-1 および scram-sha-256 です。デフォルト値は scram-sha-256 です。

iteration-count-index

パスワードの iteration count (反復回数) (サポートされている場合) を表す認証クエリーからの列インデックス。

password-index

ユーザーのパスワードを表す認証クエリーからのコラムインデックス。

salt-index

パスワードの salt (サポートされている場合) を表す認証クエリーからのコラムインデックス。

表A.56 kerberos-security-factory 属性

属性説明

debug

true の場合、認証情報を取得する JAAS ステップでデバッグロギングが有効になります。デフォルトは false です。

mechanism-names

認証情報を使用できるメカニズム名。名前は OID に変換され、mechanism-oids 属性からの OID とともに使用されます。

mechanism-oids

認証情報を使用できるメカニズム OID のリスト。

minimum-remaining-lifetime

キャッシュされた認証情報を再作成するまでの秒数。

obtain-kerberos-ticket

KerberosTicket は、認証情報と関連付ける必要があります。これは、認証情報がサーバーに委任される場合に true である必要があります。

options

Krb5LoginModule 追加オプション。

path

認証情報を取得するために読み込む keytab のパス。

principal

キータブで表されるプリンシパル。

relative-to

キータブへの相対パス。

request-lifetime

新しく作成された認証情報に要求する有効期間。

required

サービスの開始時に、十分なプリンシパルを持つキータブファイルが存在する必要があるかどうか。

server

true の場合、このファクトリーは Kerberos 認証のサーバー側の部分に使用されます。false の場合、クライアント側の使用に使用されます。デフォルト値は true です。

wrap-gss-credential

誤った不一致を防ぐために、生成された GSS 認証情報をラップすべきかどうか。

表A.57 key-manager 属性

属性説明

algorithm

基礎となる KeyManagerFactory を作成するために使用するアルゴリズムの名前。これは JDK によって提供されます。たとえば、SunJSSE を使用する JDK は、PKIX および SunX509 アルゴリズムを提供します。SunJSSE の詳細は、『Java Secure Socket Extension (JSSE) Reference Guide』を参照してください。

alias-filter

キーストアから返されるエイリアスに適用するフィルター。これは、返すエイリアスのコンマ区切りの一覧または次のいずれかの形式で指定できます。

  • ALL:-alias1:-alias2
  • NONE:+alias1:+alias2

credential-reference

キーストア項目を復号化するための認証情報リファレンス。これはクリアテキストで、または credential-store に保存されている認証情報への参照として指定できます。これはキーストアのパスワードではありません。

key-store

基礎となる KeyManagerFactory の初期化に使用する key-store への参照。

provider-name

基礎となる KeyManagerFactory を作成するために使用するプロバイダーの名前。

providers

基礎となる KeyManagerFactory の作成時に使用する Provider[] を取得するための参照。

表A.58 key-store 属性

属性説明

alias-filter

キーストアから返されるエイリアスに適用するフィルターは、返すエイリアスのコンマ区切りリストまたは以下の形式のいずれかになります。

  • ALL:-alias1:-alias2
  • NONE:+alias1:+alias2
注記

alias-filter 属性は、大文字と小文字を区別します。elytronAppServer などの大文字・小文字を合わせたエイリアスまたは大文字のエイリアスの使用は一部のキーストアプロバイダーで認識されない可能性があるため、elytronappserver などの小文字のエイリアスを使用することが推奨されます。

credential-reference

キーストアへのアクセスに使用するパスワード。これはクリアテキストで、または credential-store に保存されている認証情報への参照として指定できます。

path

キーストアファイルへのパス。

provider-name

キーストアのロードに使用するプロバイダーの名前。この属性を設定すると、指定したタイプのキーストアを作成できる最初のプロバイダーの検索が無効になります。

providers

検索するプロバイダーインスタンスの一覧を取得するために使用されるプロバイダーへの参照。指定しない場合は、代わりにプロバイダーのグローバル一覧が使用されます。

relative-to

このストアが相対するベースパス。完全パスまたは jboss.server.config.dir などの事前定義パスを指定できます。

required

true の場合は、キーストアサービスの開始時に存在するキーストアファイルが必要になります。デフォルト値は false です。

type

キーストアのタイプ (JKSなど)。

注記

以下のキーストアタイプが自動的に検出されます。

  • JKS
  • JCEKS
  • PKCS12
  • BKS
  • BCFKS
  • UBER

その他のキーストアタイプは手動で指定する必要があります。

キーストアタイプの完全なリストは、『Java Cryptography Architecture Standard Algorithm Name Documentation for JDK 8』を参照してください。

表A.59 key-store-realm 属性

属性説明

key-store

このセキュリテーレルムに使用されるキーストアへの参照。

表A.60 ldap-key-store 属性

属性説明

alias-attribute

項目エイリアスが保存される LDAP 属性の名前。

certificate-attribute

証明書が保存される LDAP 属性の名前。

certificate-chain-attribute

証明書チェーンが保存される LDAP 属性の名前。

certificate-chain-encoding

証明書チェーンのエンコーディング。

certificate-type

証明書のタイプ。

dir-context

LDAP サーバーとの通信に使用される dir-context の名前。

filter-alias

エイリアス別にキーストア内のアイテムを取得するための LDAP フィルター。

filter-certificate

証明書ごとにキーストア内のアイテムを取得するための LDAP フィルター。

filter-iterate

キーストアのすべての項目を繰り返し処理するための LDAP フィルター。

key-attribute

キーが保存される LDAP 属性の名前。

key-type

LDAP 属性でシリアル化された方法で保存されるキーストアのタイプ。例: JKS です。キーストアタイプの完全なリストは、『Java Cryptography Architecture Standard Algorithm Name Documentation for JDK 8』を参照してください。

new-item-template

項目作成の設定。これは、新しく作成されたキーストア項目の LDAP エントリーの表示方法を定義します。

search-path

キーストア項目を検索する LDAP のパス。

search-recursive

LDAP 検索を再帰的にする場合。

search-time-limit

LDAP からキーストアアイテムを取得するための時間制限 (ミリ秒単位)。デフォルトは 10000 です。

表A.61 ldap-key-store new-item-template 属性

属性説明

new-item-attributes

新しく作成されたアイテムに設定される LDAP 属性。これは、namevalue を持つ項目のリストを取得します。

new-item-path

新しく作成されたキーストア項目が保存される LDAP のパス。

new-item-rdn

新しく作成された項目に対する LDAP RDN の名前。

表A.62 ldap-realm 属性

属性説明

allow-blank-password

このレルムが、空のパスワードの直接検証に対応しているかどうか。空のパスワードを試みると拒否されます。

dir-context

LDAP サーバーへの接続に使用される dir-context の名前。

直接検証

true の場合、認証中のアカウントとして LDAP に直接接続することで認証情報の検証に対応します。そうでない場合は、パスワードは LDAP サーバーから取得され、JBoss EAP で検証されます。有効にする場合は、JBoss EAP サーバーがクライアントからユーザーのプレーンパスワードを取得できなければなりません。これには、認証に PLAIN SASL または BASIC HTTP メカニズムのいずれかを使用する必要があります。デフォルトは false です。

identity-mapping

基礎となる LDAP サーバーで対応するエントリーにプリンシパルをマッピングする方法を定義する設定オプション。

表A.63 ldap-realm identity-mapping 属性

属性説明

rdn-identifier

LDAP エントリーからプリンシパル名を取得するために使用されるプリンシパルの DN の RDN 部分。これは新規アイデンティティーの作成時にも使用されます。

use-recursive-search

true の場合、アイデンティティー検索クエリーは再帰的になります。デフォルトは false です。

search-base-dn

アイデンティティーを検索するベース DN。

attribute-mapping

このリソースに定義された属性マッピングのリスト。

filter-name

名前でアイデンティティーを取得する LDAP フィルター。

iterator-filter

レルムのアイデンティティーを繰り返し処理する LDAP フィルター。

new-identity-parent-dn

新しく作成されたアイデンティティーの親の DN。レルムの変更に必要。

new-identity-attributes

新しく作成されたアイデンティティーの属性一覧。これはレルムの変更に必要です。これは、namevalue ペアオブジェクトです。

user-password-mapper

userPassword と同様の認証情報の認証情報のマッピング。

otp-credential-mapper

OTP 認証情報の認証情報のマッピング。

x509-credential-mapper

X509 認証情報のストレージとして LDAP を使用できる設定。-from 子属性が定義されていない場合は、この設定は無視されます。複数の -from 子属性が定義されている場合、ユーザー証明書は定義されたすべての基準に一致する必要があります。

表A.64 ldap-realm identity-mapping attribute-mapping 属性

属性説明

extract-rdn

Raw 形式の値が X.500 形式の場合に、属性の値として使用する RDN キー。

filter

特定の属性の値を取得するために使用するフィルター。

filter-base-dn

フィルターが実行されるコンテキストの名前。

from

アイデンティティー属性にマッピングするための LDAP 属性の名前。定義されていない場合は、エントリーの DN が使用されます。

reference

値を取得するエントリーの DN を含む LDAP 属性の名前。

role-recursion

再帰的なロール割り当ての最大深度。0 で、再起なしを指定します。デフォルトは 0 です。

role-recursion-name

ロールエントリーの LDAP 属性を確認します。これは、ロールのロール検索時に filter-name の "{0}" に代わるものです。

search-recursive

true 属性の場合、LDAP 検索クエリーは再帰的になります。デフォルト値は true です。

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

特定の LDAP 属性からマップされたアイデンティティー属性の名前。指定されない場合、属性の名前は from の定義と同じになります。from も定義されていない場合は、dn が使用されます。

表A.65 ldap-realm identity-mapping user-password-mapper 属性

属性説明

from

アイデンティティー属性にマッピングするための LDAP 属性の名前。定義されていない場合は、エントリーの DN が使用されます。

verifiable

true パスワードを使用してユーザーを検証できる場合。デフォルト値は true です。

writable

true の場合は、パスワードを変更できます。デフォルトは false です。

表A.66 ldap-realm identity-mapping otp-credential-mapper 属性

属性説明

algorithm-from

OTP アルゴリズムの LDAP 属性の名前。

hash-from

OTP ハッシュ関数の LDAP 属性の名前。

seed-from

OTP シードの LDAP 属性の名前。

sequence-from

OTP シーケンス番号の LDAP 属性名。

表A.67 ldap-realm identity-mapping x509-credential-mapper 属性

属性説明

certificate-from

エンコードされたユーザー証明書にマップする LDAP 属性の名前。定義されていない場合は、エンコードされた証明書はチェックされません。

digest-algorithm

ユーザー証明書のダイジェストを計算するために使用される、ハッシュ関数のダイジェストアルゴリズム。digest-from が定義されている場合にのみ使用されます。

digest-from

ユーザー証明書ダイジェストにマップする LDAP 属性の名前。定義されていない場合、証明書のダイジェストはチェックされません。

serial-number-from

ユーザー証明書のシリアル番号にマップする LDAP 属性の名前。定義されていない場合は、シリアル番号はチェックされません。

subject-dn-from

ユーザー証明書のサブジェクト DN にマップする LDAP 属性の名前。定義されていない場合、サブジェクト DN はチェックされません。

表A.68 logical-permission-mapper 属性

属性説明

left

操作の左側に対して使用するパーミッションマッパーへの参照。

logical-operation

パーミッションマッパーを組み合わせるために使用する論理操作。使用できる値は、andorxor、および unlessです。

right

操作の右側に対して使用するパーミッションマッパーへの参照。

表A.69 logical-role-mapper 属性

属性説明

left

操作の左側で使用されるロールマッパーへの参照。

logical-operation

ロールマッパーマッピングで実行される論理操作。使用できる値は、andminusorxor です。

right

操作の右側で使用されるロールマッパーへの参照。

表A.70 mapped-regex-realm-mapper 属性

属性説明

delegate-realm-mapper

パターンを使用して一致がない場合に委譲するレルムマッパー。

pattern

名前からレルムを抽出するために少なくとも 1 つのキャプチャーグループが含まれる必要がある正規表現。

realm-map

正規表現を使用して抽出したレルム名の定義レルム名へのマッピング。

表A.71 mechanism-provider-filtering-sasl-server-factory 属性

属性説明

有効化

true の場合は、フィルターのいずれかと一致しない限り、プロバイダーの読み込みメカニズムが有効ではありません。デフォルトは true です。

filters

プロバイダーのメカニズムを比較する際に適用するフィルターの一覧です。フィルターは、指定したすべての値がメカニズムおよびプロバイダーのペアと一致する場合に一致します。

sasl-server-factory

この定義でラップされる SASL サーバーファクトリーへの参照。

表A.72 mechanism-provider-filtering-sasl-server-factory フィルター属性

属性説明

mechanism-name

このフィルターがマッチする SASL メカニズムの名前。

provider-name

このフィルターが一致したプロバイダーの名前。

provider-version

プロバイダーのバージョンを比較する際に使用するバージョン。

version-comparison

プロバイダーのバージョンを評価する際に使用する等価性。使用できる値は less-thangreater-than です。デフォルト値は less-than です。

表A.73 online-certificate-status-protocol 属性

属性説明

responder

証明書から解決した OCSP Responder URI を上書きします。

responder-certificate

responder-keystore が定義されていない場合の、responder-keystore または trust-manager キーストアに位置するレスポンダー証明書のエイリアス。

responder-keystore

レスポンダー証明書の代替キーストア。Responder-certificate を定義する必要があります。

prefer-crls

OCSP メカニズムと CRL メカニズムの両方が設定されている場合、OCSP メカニズムが最初に呼び出されます。Prefer-crlstrue に設定すると、CRL メカニズムが最初に呼び出されます。

表A.74 properties-realm 属性

属性説明

groups-attribute

アイデンティティーのグループメンバーシップ情報が含まれる必要がある、返された AuthorizationIdentity の属性の名前。

groups-properties

ユーザーおよびそれらのグループが含まれるプロパティーファイル。

users-properties

ユーザーとパスワードが含まれるプロパティーファイル。

表A.75 properties-realm users-properties 属性

属性説明

digest-realm-name

プロパティーファイルで検出されない場合に、ダイジェストされたパスワードに使用するデフォルトのレルム名。

path

ユーザーおよびパスワードを含むファイルへのパス。このファイルには、レルム名の宣言が含まれる必要があります。

plain-text

true の場合は、プレーンテキストで保存されたプロパティーファイルのパスワードを使用します。false であれば、事前にハッシュが指定されます。これは、HEX( MD5( username \":\" realm \":\" password))) の形式で取得されます。デフォルトは false です。

relative-to

パスが相対する、事前に定義されたパス。

表A.76 properties-realm groups-properties 属性

属性説明

path

ユーザーおよびそれらのグループを含むファイルへのパスです。

relative-to

パスが相対する、事前に定義されたパス。

表A.77 provider-http-server-mechanism-factory 属性

属性説明

providers

ファクトリーの検索に使用するプロバイダー。指定されない場合は、グローバルに登録されたプロバイダーの一覧が使用されます。

表A.78 provider-loader 属性

属性説明

argument

Provider がインスタンス化されるとき、コンストラクターに渡される引数。

class-names

読み込むプロバイダーの完全修飾クラス名の一覧。これらは service-loader がプロバイダーを検出した後にロードされ、重複はスキップされます。

configuration

初期化するためにプロバイダーに渡されるキーおよび値の設定。

module

プロバイダーのロード元となるモジュールの名前。

path

プロバイダーの初期化に使用するファイルのパス。

relative-to

設定ファイルのベースパス。

表A.79 provider-sasl-server-factory 属性

属性説明

providers

ファクトリーの検索に使用するプロバイダー。指定されない場合は、グローバルに登録されたプロバイダーの一覧が使用されます。

表A.80 regex-principal-transformer 属性

属性説明

pattern

置き換える名前の一部を見つけるために使用する正規表現。

replace-all

true の場合は、一致するすべてのパターンが置き換えられます。false の場合は、最初に出現したもののみが置き換えられます。デフォルトは false です。

replacement

代替として使用する値。

表A.81 regex-validating-principal-transformer 属性

属性説明

match

true の場合、検証を成功させるには、指定したパターンに名前が一致する必要があります。false の場合、検証を成功させるには、指定したパターンに名前が一致することはできません。デフォルトは true です。

pattern

プリンシパルトランスフォーマーに使用する正規表現。

表A.82 sasl-authentication-factory 属性

属性説明

mechanism-configurations

メカニズム固有の設定のリスト。

sasl-server-factory

このリソースに関連付ける SASL サーバーファクトリー。

security-domain

このリソースに関連付けるセキュリティードメイン。

表A.83 sasl-authentication-factory mechanism-configurations 属性

属性説明

credential-security-factory

メカニズムで必要な認証情報の取得に使用するセキュリティーファクトリー。

final-principal-transformer

このメカニズムレルムに適用する最終のプリンシパルトランスフォーマー。

host-name

この設定が適用されるホスト名。

mechanism-name

この設定は、名前を指定したメカニズムが使用される場合にのみ適用されます。この属性を省略すると、メカニズム名に一致します。

mechanism-realm-configurations

メカニズムが理解するレルム名の定義の一覧です。

protocol

この設定が適用されるプロトコル。

post-realm-principal-transformer

レルムの選択後に適用するプリンシパルトランスフォーマー。

pre-realm-principal-transformer

レルムが選択される前に適用するプリンシパルトランスフォーマー。

realm-mapper

メカニズムによって使用されるレルムマッパー。

表A.84 sasl-authentication-factory mechanism-configurations mechanism-realm-configurations 属性

属性説明

final-principal-transformer

このメカニズムレルムに適用する最終のプリンシパルトランスフォーマー。

post-realm-principal-transformer

レルムの選択後に適用するプリンシパルトランスフォーマー。

pre-realm-principal-transformer

レルムが選択される前に適用するプリンシパルトランスフォーマー。

realm-mapper

メカニズムによって使用されるレルムマッパー。

realm-name

メカニズムにより提示されるレルムの名前。

表A.85 server-ssl-context 属性

属性説明

authentication-optional

true の場合、セキュリティードメインがクライアント証明書を拒否しても接続は妨害されません。このため、フォールスルーにより、クライアント証明書がセキュリティードメインによって拒否される場合に、別の認証メカニズム (フォームログインなど) を使用できます。これはセキュリティードメインが設定されている場合に限り有効になります。デフォルトは false です。

cipher-suite-filter

有効な暗号スイートを指定するために適用するフィルター。このフィルターは、コロン、コンマ、またはスペースで区切られた項目の一覧を取得します。各項目は、OpenSSL 形式の暗号スイート名、標準の SSL/TLS 暗号スイート名、または TLSv1.2DES などのキーワードになります。キーワードの詳細な一覧およびフィルター作成の詳細は、『CipherSuiteSelector』の Javadoc で掲載されています。デフォルト値は DEFAULT で、NULL 暗号化のない既知の暗号スイートすべてに対応し、認証のない暗号スイートを除外します。

final-principal-transformer

このメカニズムレルムに適用する最終のプリンシパルトランスフォーマー。

key-manager

SSLContext 内で使用するキーマネージャーへの参照。

maximum-session-cache-size

キャッシュされる SSL/TLS セッションの最大数。

need-client-auth

true の場合は、SSL ハンドシェイクでクライアント証明書が必要になります。信頼されたクライアント証明書がない接続は拒否されます。デフォルトは false です。

post-realm-principal-transformer

レルムの選択後に適用するプリンシパルトランスフォーマー。

pre-realm-principal-transformer

レルムが選択される前に適用するプリンシパルトランスフォーマー。

プロトコル

有効なプロトコル。利用できるオプションは SSLv2SSLv3TLSv1TLSv1.1TLSv1.2TLSv1.3 です。これは、デフォルトで TLSv1TLSv1.1TLSv1.2、および TLSv1.3 を有効にするように設定されています。

警告

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

provider-name

使用するプロバイダーの名前。指定されていない場合は、プロバイダーからのプロバイダーはすべて SSLContext に渡されます。

providers

SSLContext の読み込みに使用する Provider[] を取得するプロバイダーの名前。

realm-mapper

SSL 認証に使用するレルムマッパー。

security-domain

SSL/TLS セッション確立中の認証に使用するセキュリティードメイン。

session-timeout

SSL/TLS セッションのタイムアウト。

trust-manager

SSLContext 内で使用する trust-manager への参照。

use-cipher-suites-order

true の場合は、サーバーに定義された暗号スイートの順序が使用されます。false の場合は、クライアントによって示される暗号スイートの順序が使用されます。デフォルト値は true です。

want-client-auth

true の場合、SSL ハンドシェイクでクライアント証明書がリクエストされますが、必須ではありません。セキュリティードメインが参照され、X509 エビデンスがサポートされる場合、これは自動的に true に設定されます。これは、need-client-auth が設定されると無視されます。デフォルトは false です。

wrap

true の場合は、返された SSLEngineSSLSocket、および SSLServerSocket インスタンスがラップされ、さらなる変更に対して保護されます。デフォルトは false です。

注記

server-ssl-context のレリムマッパーやプリンシパルトランスフォーマー属性は、証明書がトラストマネージャーによって検証される、SASL EXTERNAL メカニズムにのみ適用されます。HTTP CLIENT-CERT 認証設定は、http-authentication-factory で設定されます。

表A.86 service-loader-http-server-mechanism-factory 属性

属性説明

module

ファクトリーをロードするクラスローダーの取得に使用するモジュール。指定のない場合は、リソースをロードするクラスローダーが代わりに使用されます。

表A.87 service-loader-sasl-server-factory 属性

属性説明

module

ファクトリーをロードするクラスローダーの取得に使用するモジュール。指定のない場合は、リソースをロードするクラスローダーが代わりに使用されます。

表A.88 simple-permission-mapper 属性

属性説明

mapping-mode

複数の一致の場合に使用すべきマッピングモード。使用できる値は、areandorxorunlessfirst です。デフォルトは first です。

permission-mappings

定義されたパーミッションマッピングのリスト。

表A.89 simple-permission-mapper permission-mappings 属性

属性説明

permission-sets

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

permission-set は以下の属性を取ることができます。

  • permission-set

    パーミッションセットへの参照。

重要

permissions 属性は非推奨となり、permission-sets に置き換えられました。

principals

パーミッションをマッピングする際に比較するプリンシパルの一覧。アイデンティティープリンシパルがリストの何かしらと一致する場合、それがマッチとなります。

roles

パーミッションをマッピングするときに比較するロールのリスト。アイデンティティがリストの何かしらのメンバーである場合は、それが一致となります。

表A.90 permission-set パーミッション属性

属性説明

action

構築されるときにパーミッションに渡すアクション。

class-name

パーミッションの完全修飾クラス名。

module

パーミッションのロードに使用するモジュール。

target-name

構築されるときにパーミッションに渡すターゲット名。

表A.91 simple-regex-realm-mapper 属性

属性説明

delegate-realm-mapper

パターンを使用して一致がない場合に委譲するレルムマッパー。

pattern

名前からレルムを抽出するために少なくとも 1 つのキャプチャーグループが含まれる必要がある正規表現。

表A.92 simple-role-decoder 属性

属性説明

attribute

直接ロールにマップするアイデンティティーの属性名。

表A.93 source-address-role-decoder 属性

属性説明

pattern

照合するクライアントの IP アドレスまたはクライアントの IP アドレスを指定する正規表現。

source-address

クライアントの IP アドレスを指定します。

roles

クライアントの IP アドレスが pattern 属性または source-address 属性で指定された値と一致する場合に、ユーザーに割り当てるロールの一覧を提供します。

注記

source-address 属性または pattern 属性のいずれかで、IP アドレスを少なくとも 1 つ指定する必要があります。それ以外の場合は、クライアントの IP アドレスに基づいて承認の決定を行うことはできません。

表A.94 syslog-audit-log 属性

属性説明

format

監査イベントを記録する形式。

サポートされる値:

  • SIMPLE
  • JSON

デフォルト値:

  • SIMPLE

host-name

syslog サーバーに送信されるすべてのイベントに組み込むホスト名。

port

syslog サーバーのリッスンポート。

reconnect-attempts

接続を閉じる前に Elytron が連続メッセージを syslog サーバーに送信試行する最大回数。この属性の値は、使用される送信プロトコルが UDP の場合にのみ有効です。

サポートされる値:

  • 正の integer
  • -1 は、再接続が無限に試行されることを示します。

デフォルト値:

  • 0

server-address

syslog サーバーの IP アドレス、または Java の InetAddress.getByName() メソッドによって解決できる名前。

ssl-context

syslog サーバーへの接続時に使用する SSL コンテキスト。この属性は、transportSSL_TCP に設定されている場合にのみ必要です。

syslog-format

監査イベントの記述に使用される RFC 形式。

サポートされる値:

  • RFC5424
  • RFC3164

デフォルト値:

  • RFC5424

transport

syslog サーバーへの接続に使用するトランスポート層プロトコル。

サポートされる値:

  • UDP
  • TCP
  • SSL_TCP

デフォルト値:

  • TCP

表A.95 token-realm 属性

属性説明

jwt

JWT/JWS 規格に基づくセキュリティートークンを処理するトークンベースのレルムとともに使用されるトークンバリデーター。

oauth2-introspection

トークンベースのレルムとともに使用されるトークンバリデーター。これは、OAuth2 アクセストークンを処理し、RFC-7662 OAuth2 Token Introspection 仕様に準拠するエンドポイントを使用して、このトークンを検証します。

principal-claim

プリンシパルの名前を取得するために使用される要求の名前。デフォルトは username です。

表A.96 token-realm jwt 属性

属性説明

audience

この設定でサポートされる対象を表す文字列の一覧。検証の際には、JWT トークンに、ここで定義した値のいずれかが含まれる aud 要求が必要です。

certificate

key-store 属性で定義されるキーストアからロードする公開鍵を持つ証明書の名前。

client-ssl-context

リモート JSON Web Key (JWK) に使用する SSL コンテキスト。これにより、jku (JSON Key URL) ヘッダーパラメーターの URL を使用して、トークンの検証用に公開鍵を取得できます。

host-name-verification-policy

</