Menu Close

第2章 Apache Karaf コンテナーの保護

概要

Apache Karaf コンテナーは JAAS を使用してセキュア化されます。JAAS レルムを定義することで、ユーザークレデンシャルの取得に使用されるメカニズムを設定できます。また、デフォルトのロールを変更することで、コンテナーの管理インターフェースへのアクセスを調整することもできます。

2.1. JAAS 認証

概要

Java Authentication and Authorization Service (JAAS) は、Java アプリケーションで認証を実装する一般的なフレームワークを提供します。認証の実装はモジュール化され、個々の JAAS モジュール (またはプラグイン) により認証の実装が提供されます。

JAAS の詳細は『JAAS Reference Guide』を参照してください。

2.1.1. デフォルトの JAAS レルム

ここでは、Karaf コンテナーのデフォルトの JAAS レルムのユーザーデータを管理する方法について説明します。

デフォルトの JAAS レルム

Karaf コンテナーには事前定義された JAAS レルムである karaf レルムがあります。これはデフォルトで、コンテナーのすべての側面をセキュアにするために使用されます。

アプリケーションを JAAS と統合する方法

独自のアプリケーションで karaf レルムを使用できます。karaf を、使用する JAAS レルムの名前として設定するだけです。

デフォルトの JAAS ログインモジュール

Karaf コンテナーを初めて起動する場合、karaf デフォルトレルムを使用するように設定されています。このデフォルト設定では、karaf レルムは 5 つの JAAS ログインモジュールをデプロイし、同時に有効にします。デプロイされたログインモジュールを表示するには、以下のように jaas:realms コンソールコマンドを入力します。

Index │ Realm Name │ Login Module Class Name
──────┼────────────┼───────────────────────────────────────────────────────────────
1     │ karaf      │ org.apache.karaf.jaas.modules.properties.PropertiesLoginModule
2     │ karaf      │ org.apache.karaf.jaas.modules.publickey.PublickeyLoginModule
3     │ karaf      │ org.apache.karaf.jaas.modules.audit.FileAuditLoginModule
4     │ karaf      │ org.apache.karaf.jaas.modules.audit.LogAuditLoginModule
5     │ karaf      │ org.apache.karaf.jaas.modules.audit.EventAdminAuditLoginModule

ユーザーがログインを試みるたびに、認証は 5 つのモジュールを一覧順に処理します。各モジュールのフラグ値は、認証を成功させるためにモジュールが正常に完了する必要があるかどうかを指定します。フラグ値は、モジュールの完了後に認証プロセスを停止するか、または次のモジュールに進むかどうかも指定します。

Optional フラグは、5 つの認証モジュールすべてに設定されます。Optional フラグ設定により、現在のモジュールが正常に完了するかどうかにかかわらず、認証プロセスが常に 1 つのモジュールから次のモジュールに渡されます。Karaf JAAS レルムのフラグ値はハードコーディングされており、変更はできません。フラグの詳細については、表2.1「JAAS モジュールを定義するフラグ」 を参照してください。

重要

Karaf コンテナーでは、プロパティーログインモジュールと公開鍵ログインモジュールの両方が有効になります。JAAS がユーザーを認証するとき、最初にプロパティーログインモジュールでユーザーの認証を試みます。これに失敗すると、公開鍵ログインモジュールでユーザーを認証しようとします。そのモジュールも失敗すると、エラーが発生します。

2.1.1.1. 認証監査ロギングモジュール

Karaf コンテナーのデフォルトモジュールのリスト内で、最初の 2 つのモジュールのみがユーザーアイデンティティーの検証に使用されます。残りのモジュールは、成功および失敗したログイン試行の監査証跡をログに記録するために使用されます。デフォルトのレルムには、以下の監査ロギングモジュールが含まれます。

org.apache.karaf.jaas.modules.audit.LogAuditLoginModule
このモジュールは、etc/org.ops4j.pax.logging.cfg ファイル内の Pax ロギングインフラストラクチャーに設定されたロガーを使用して、認証の試行に関する情報を記録します。詳細は、「JAAS ログ監査ログインモジュール」を参照してください。
org.apache.karaf.jaas.modules.audit.FileAuditLoginModule
このモジュールは、認証試行に関する情報を指定したファイルに直接記録します。ロギングインフラストラクチャーを使用しません。詳細は、「JAAS ファイル監査ログインモジュール」を参照してください。
org.apache.karaf.jaas.modules.audit.EventAdminAuditLoginModule
このモジュールは、OSGi Event Admin サービスを使用して認証の試行を追跡します。

プロパティーログインモジュールでのユーザーの設定

プロパティーログインモジュールは、ユーザー名/パスワードクレデンシャルをフラットファイル形式で保存するために使用されます。プロパティーログインモジュールで新規ユーザーを作成するには、テキストエディターを使用して InstallDir/etc/users.properties ファイルを開き、以下の構文の行を追加します。

Username=Password[,UserGroup|Role][,UserGroup|Role]...

たとえば、パスワード topsecret およびロール adminjdoe ユーザーを作成するには、以下のようなエントリーを作成します。

jdoe=topsecret,admin

ここで、admin ロールは jdoe ユーザーに完全な管理権限を付与します。

プロパティーログインモジュールでのユーザーグループの設定

ロールをユーザーに直接割り当てる代わりに (またはそれに加えて)、プロパティーログインモジュールでユーザーをユーザーグループに追加するオプションもあります。プロパティーログインモジュールでユーザーグループを作成するには、テキストエディターを使用して InstallDir/etc/users.properties ファイルを開き、以下の構文の行を追加します。

_g_\:GroupName=Role1,Role2,...

たとえば、ロール group および adminadmingroup ユーザーグループを作成するには、以下のようなエントリーを作成します。

_g_\:admingroup=group,admin

以下のユーザーエントリーを作成して、majorclanger ユーザーを admingroup に追加します。

majorclanger=secretpass,_g_:admingroup

公開鍵ログインモジュールの設定

公開鍵のログインモジュールは、SSH 公開鍵のクレデンシャルをフラットファイル形式で保存するために使用されます。公開鍵ログインモジュールで新規ユーザーを作成するには、テキストエディターを使用して InstallDir/etc/keys.properties ファイルを開き、以下の構文の行を追加します。

Username=PublicKey[,UserGroup|Role][,UserGroup|Role]...

たとえば、以下のエントリーを 1 行で InstallDir/etc/keys.properties ファイルに追加することで、admin ロールで jdoe ユーザーを作成できます。

jdoe=AAAAB3NzaC1kc3MAAACBAP1/U4EddRIpUt9KnC7s5Of2EbdSPO9EAMMeP4C2USZpRV1AIlH7WT2NWPq/xfW6MPbLm1Vs14E7gB00b/JmYLdrmVClpJ+f6AR7ECLCT7up1/63xhv4O1fnfqimFQ8E+4P208UewwI1VBNaFpEy9nXzrith1yrv8iIDGZ3RSAHHAAAAFQCXYFCPFSMLzLKSuYKi64QL8Fgc9QAAAnEA9+GghdabPd7LvKtcNrhXuXmUr7v6OuqC+VdMCz0HgmdRWVeOutRZT+ZxBxCBgLRJFnEj6EwoFhO3zwkyjMim4TwWeotifI0o4KOuHiuzpnWRbqN/C/ohNWLx+2J6ASQ7zKTxvqhRkImog9/hWuWfBpKLZl6Ae1UlZAFMO/7PSSoAAACBAKKSU2PFl/qOLxIwmBZPPIcJshVe7bVUpFvyl3BbJDow8rXfskl8wO63OzP/qLmcJM0+JbcRU/53Jj7uyk31drV2qxhIOsLDC9dGCWj47Y7TyhPdXh/0dthTRBy6bqGtRPxGa7gJov1xm/UuYYXPIUR/3x9MAZvZ5xvE0kYXO+rx,admin
重要

ここで、id_rsa.pub ファイルの内容をすべて挿入しないでください。公開鍵自体を表すシンボルのブロックのみを挿入します。

公開鍵ログインモジュールでのユーザーグループの設定

ロールをユーザーに直接割り当てる代わりに (またはそれに加えて)、公開鍵ログインモジュールでユーザーをユーザーグループに追加するオプションもあります。公開鍵ログインモジュールでユーザーグループを作成するには、テキストエディターを使用して InstallDir/etc/keys.properties ファイルを開き、以下の構文の行を追加します。

_g_\:GroupName=Role1,Role2,...

たとえば、ロール group および adminadmingroup ユーザーグループを作成するには、以下のようなエントリーを作成します。

_g_\:admingroup=group,admin

以下のユーザーエントリーを作成して、jdoe ユーザーを admingroup に追加します。

jdoe=AAAAB3NzaC1kc3MAAACBAP1/U4EddRIpUt9KnC7s5Of2EbdSPO9EAMMeP4C2USZpRV1AIlH7WT2NWPq/xfW6MPbLm1Vs14E7gB00b/JmYLdrmVClpJ+f6AR7ECLCT7up1/63xhv4O1fnfqimFQ8E+4P208UewwI1VBNaFpEy9nXzrith1yrv8iIDGZ3RSAHHAAAAFQCXYFCPFSMLzLKSuYKi64QL8Fgc9QAAAnEA9+GghdabPd7LvKtcNrhXuXmUr7v6OuqC+VdMCz0HgmdRWVeOutRZT+ZxBxCBgLRJFnEj6EwoFhO3zwkyjMim4TwWeotifI0o4KOuHiuzpnWRbqN/C/ohNWLx+2J6ASQ7zKTxvqhRkImog9/hWuWfBpKLZl6Ae1UlZAFMO/7PSSoAAACBAKKSU2PFl/qOLxIwmBZPPIcJshVe7bVUpFvyl3BbJDow8rXfskl8wO63OzP/qLmcJM0+JbcRU/53Jj7uyk31drV2qxhIOsLDC9dGCWj47Y7TyhPdXh/0dthTRBy6bqGtRPxGa7gJov1xm/UuYYXPIUR/3x9MAZvZ5xvE0kYXO+rx,_g_:admingroup

保存されたパスワードの暗号化

デフォルトでは、パスワードはプレーンテキスト形式で InstallDir/etc/users.properties ファイルに保存されます。このファイルでパスワードを保護するには、管理者のみが読み取ることができるように users.properties ファイルのファイル権限を設定する必要があります。追加の保護機能を提供するために、オプションでメッセージダイジェストアルゴリズムを使用して保存されたパスワードを暗号化できます。

パスワード暗号化機能を有効にするには、InstallDir/etc/org.apache.karaf.jaas.cfg ファイルを編集して、コメントで説明されているように暗号化プロパティーを設定します。たとえば、以下の設定は、MD5 メッセージダイジェストアルゴリズムを使用して Basic 暗号化を有効にします。

encryption.enabled = true
encryption.name = basic
encryption.prefix = {CRYPT}
encryption.suffix = {CRYPT}
encryption.algorithm = MD5
encryption.encoding = hexadecimal
注記

org.apache.karaf.jaas.cfg ファイルの暗号化設定は、Karaf コンテナーのデフォルトの karaf レルムのみに適用されます。カスタムレルムには影響しません。

パスワード暗号化の詳細は、「保存されたパスワードの暗号化」 を参照してください。

デフォルトレルムのオーバーライド

JAAS レルムをカスタマイズする場合、最も便利なアプローチは、より高いランクの karaf レルムを定義してデフォルトの karaf レルムをオーバーライドすることです。これにより、すべての Red Hat Fuse セキュリティーコンポーネントがカスタムレルムを使用するようになります。カスタム JAAS レルムの定義とデプロイ方法の詳細については、「JAAS レルムの定義」 を参照してください。。

2.1.2. JAAS レルムの定義

OSGi コンテナーで JAAS レルムを定義する場合、従来の JAAS ログイン設定 ファイルに定義を配置することはできません。代わりに、OSGi コンテナーは、Blueprint 設定ファイルで JAAS レルムを定義するために特別な jaas:config 要素を使用します。この方法で定義された JAAS レルムは、コンテナーにデプロイされたすべてのアプリケーションバンドルで利用できるようになり、コンテナー全体で JAAS セキュリティーインフラストラクチャーを共有できるようになります。

namespace

jaas:config 要素は http://karaf.apache.org/xmlns/jaas/v1.0.0 namespace で定義されます。JAAS レルムを定義する場合は、例2.1「JAAS Blueprint namespace」 に示されてい行が含まれるようにする必要があります。

例2.1 JAAS Blueprint namespace

xmlns:jaas="http://karaf.apache.org/xmlns/jaas/v1.0.0"

JAAS レルムの設定

jaas:config 要素の構文は 例2.2「Blueprint XML での JAAS レルムの定義」 に示されています。

例2.2 Blueprint XML での JAAS レルムの定義

<blueprint xmlns="http://www.osgi.org/xmlns/blueprint/v1.0.0"
           xmlns:jaas="http://karaf.apache.org/xmlns/jaas/v1.0.0">

    <jaas:config name="JaasRealmName"
                 rank="IntegerRank">
        <jaas:module className="LoginModuleClassName"
                     flags="[required|requisite|sufficient|optional]">
            Property=Value
            ...
        </jaas:module>
        ...
        <!-- Can optionally define multiple modules -->
        ...
    </jaas:config>

</blueprint>

以下のように要素が使用されます。

jaas:config

JAAS レルムを定義します。これには以下の属性があります。

  • name - JAAS レルムの名前を指定します。
  • rank - JAAS レルム間で命名の競合を解決するためのオプションのランクを指定します。同じ名前の JAAS レルムを 2 つ以上登録すると、OSGi コンテナーは常に最も高いランクのレルムインスタンスを選択します。デフォルトのレルム karaf を上書きする場合は、以前にインストールされた karaf レルムをすべてオーバーライドするように、rank100 以上に設定する必要があります。
jaas:module

現在のレルムで JAAS ログインモジュールを定義します。jaas:module には以下の属性があります。

  • className - JAAS ログインモジュールの完全修飾クラス名。指定したクラスはバンドルクラスローダーから利用できる必要があります。
  • flags - ログイン操作の成功または失敗時に何が起こるかを決定します。表2.1「JAAS モジュールを定義するフラグ」 に有効な値を説明します。

    表2.1 JAAS モジュールを定義するフラグ

    説明

    required

    このログインモジュールの認証は成功する必要があります。成功または失敗に関係なく、常にこのエントリーの次のログインモジュールに進みます。

    requisite

    このログインモジュールの認証は成功する必要があります。成功した場合は、次のログインモジュールに進みます。失敗した場合は、残りのログインモジュールを処理せずにすぐに戻ります。

    sufficient

    このログインモジュールの認証は、成功のために必要ありません。成功した場合は、残りのログインモジュールを処理せずにすぐに戻ります。失敗した場合は、次のログインモジュールに進みます。

    optional

    このログインモジュールの認証は、成功のために必要ありません。成功または失敗に関係なく、常にこのエントリーの次のログインモジュールに進みます。

    jaas:module 要素の内容は、JAAS ログインモジュールインスタンスの初期化に使用されるプロパティー設定のスペース区切りリストです。特定のプロパティーは JAAS ログインモジュールによって決定され、適切な形式にする必要があります。

    注記

    レルムに複数のログインモジュールを定義できます。

標準の JAAS ログインプロパティーの XML への変換

Red Hat Fuse では、標準の Java ログイン設定ファイルと同じプロパティーを使用しますが、Red Hat Fuse では若干異なる指定が必要です。JAAS レルムの定義に対する Red Hat Fuse のアプローチと標準の Java ログイン設定ファイルアプローチを比較するには、例2.3「標準の JAAS プロパティー」 に示すログイン設定を変換する方法を考慮します。これは、Red Hat Fuse プロパティーログインモジュールクラス PropertiesLoginModule を使用して PropertiesLogin レルムを定義します。

例2.3 標準の JAAS プロパティー

PropertiesLogin {
    org.apache.activemq.jaas.PropertiesLoginModule required
        org.apache.activemq.jaas.properties.user="users.properties"
        org.apache.activemq.jaas.properties.group="groups.properties";
};

Blueprint ファイルの jaas:config 要素を使用した、同等の JAAS レルム定義を 例2.4「Blueprint JAAS プロパティー」 に示します。

例2.4 Blueprint JAAS プロパティー

<blueprint xmlns="http://www.osgi.org/xmlns/blueprint/v1.0.0"
  xmlns:jaas="http://karaf.apache.org/xmlns/jaas/v1.0.0"
  xmlns:ext="http://aries.apache.org/blueprint/xmlns/blueprint-ext/v1.0.0">

  <jaas:config name="PropertiesLogin">
    <jaas:module flags="required"
      className="org.apache.activemq.jaas.PropertiesLoginModule">
        org.apache.activemq.jaas.properties.user=users.properties
        org.apache.activemq.jaas.properties.group=groups.properties
    </jaas:module>
  </jaas:config>

</blueprint>
重要

Blueprint 設定の JAAS プロパティーには二重引用符を使用しないでください。

Red Hat Fuse は、JAAS 認証データを X.500 サーバーに保存できるアダプターも提供します。例2.5「JAAS レルムの設定」 は、ldap://localhost:10389 にある LDAP サーバーに接続する Red Hat Fuse の LDAPLoginModule クラスを使用するよう、LDAPLogin レルムを定義します。

例2.5 JAAS レルムの設定

<?xml version="1.0" encoding="UTF-8"?>
<blueprint xmlns="http://www.osgi.org/xmlns/blueprint/v1.0.0"
  xmlns:jaas="http://karaf.apache.org/xmlns/jaas/v1.0.0"
  xmlns:ext="http://aries.apache.org/blueprint/xmlns/blueprint-ext/v1.0.0">

  <jaas:config name="LDAPLogin" rank="200">
    <jaas:module flags="required"
      className="org.apache.karaf.jaas.modules.ldap.LDAPLoginModule">
        initialContextFactory=com.sun.jndi.ldap.LdapCtxFactory
        connection.username=uid=admin,ou=system
        connection.password=secret
        connection.protocol=
        connection.url = ldap://localhost:10389
        user.base.dn = ou=users,ou=system
        user.filter = (uid=%u)
        user.search.subtree = true
        role.base.dn = ou=users,ou=system
        role.filter = (uid=%u)
        role.name.attribute = ou
        role.search.subtree = true
        authentication = simple
    </jaas:module>
  </jaas:config>
</blueprint>

LDAP ログインモジュールの使用方法と例については、「JAAS LDAP ログインモジュール」 を参照してください。

2.1.3. JAAS プロパティーログインモジュール

JAAS プロパティーログインモジュールは、ユーザーデータをフラットファイル形式で格納します (保存したパスワードは、オプションでメッセージダイジェストアルゴリズムを使用して暗号化できます)。ユーザーデータは、単純なテキストエディターを使用して直接編集することも、jaas:* コンソールコマンドを使用して管理することもできます。

たとえば、Karaf コンテナーはデフォルトで JAAS プロパティーログインモジュールを使用し、関連するユーザーデータを InstallDir/etc/users.properties ファイルに保存します。

サポートされるクレデンシャル

JAAS プロパティーログインモジュールはユーザー名/パスワードのクレデンシャルを認証し、認証されたユーザーに関連付けられたロールのリストを返します。

実装クラス

以下のクラスは JAAS プロパティーログインモジュールを実装します。

org.apache.karaf.jaas.modules.properties.PropertiesLoginModule
JAAS ログインモジュールを実装します。
org.apache.karaf.jaas.modules.properties.PropertiesBackingEngineFactory
OSGi サービスとして公開する必要があります。このサービスは、Apache Karaf シェルから jaas:* コンソールコマンドを使用してユーザーデータを管理できるようにします (『Apache Karaf Console Reference』を参照)。

オプション

JAAS プロパティーログインモジュールは、以下のオプションをサポートします。

users
ユーザープロパティーファイルの場所。

ユーザープロパティーファイルの形式

ユーザープロパティーファイルは、プロパティー ログインモジュールにユーザー名、パスワード、およびロールデータを保存するために使用されます。各ユーザーはユーザープロパティーファイルの単一の行で表され、行は以下の形式になります。

Username=Password[,UserGroup|Role][,UserGroup|Role]...

ユーザーグループはこのファイルで定義することもできます。このファイルで各ユーザーグループは、以下の形式で 1 行で表されます。

_g_\:GroupName=Role1[,Role2]...

たとえば、以下のようにユーザー bigcheese および guest、ユーザーグループ admingroup および guestgroup を定義できます。

# Users
bigcheese=cheesepass,_g_:admingroup
guest=guestpass,_g_:guestgroup

# Groups
_g_\:admingroup=group,admin
_g_\:guestgroup=viewer

Blueprint 設定の例

以下の Blueprint 設定は、プロパティーログインモジュールを使用して新しい karaf レルムを定義する方法を示しています。ここで、rank 属性を 200 に設定すると、デフォルトの karaf レルムが上書きされます。

<?xml version="1.0" encoding="UTF-8"?>
<blueprint xmlns="http://www.osgi.org/xmlns/blueprint/v1.0.0"
  xmlns:jaas="http://karaf.apache.org/xmlns/jaas/v1.0.0"
  xmlns:cm="http://aries.apache.org/blueprint/xmlns/blueprint-cm/v1.1.0"
  xmlns:ext="http://aries.apache.org/blueprint/xmlns/blueprint-ext/v1.0.0">

  <type-converters>
    <bean class="org.apache.karaf.jaas.modules.properties.PropertiesConverter"/>
  </type-converters>

<!--Allow usage of System properties, especially the karaf.base property-->
  <ext:property-placeholder
       placeholder-prefix="$[" placeholder-suffix="]"/>

  <jaas:config name="karaf" rank="200">
    <jaas:module flags="required"
className="org.apache.karaf.jaas.modules.properties.PropertiesLoginModule">
        users= $[karaf.base]/etc/users.properties
    </jaas:module>
  </jaas:config>

  <!-- The Backing Engine Factory Service for the PropertiesLoginModule -->
  <service interface="org.apache.karaf.jaas.modules.BackingEngineFactory">
    <bean class="org.apache.karaf.jaas.modules.properties.PropertiesBackingEngineFactory"/>
  </service>

</blueprint>

必ず、BackingEngineFactory Bean を OSGi サービスとしてエクスポートし、jaas:* コンソールコマンドがユーザーデータを管理できるようにします。

2.1.4. JAAS OSGi 設定ログインモジュール

概要

JAAS OSGi 設定ログインモジュールは、OSGi Config Admin Service を使用してユーザーデータを保存します。このログインモジュールは JAAS プロパティーログインモジュールとよく似ていますが (ユーザーエントリーの構文は同じです)、ユーザーデータを取得するメカニズムは OSGi Config Admin Service に基づいています。

ユーザーデータは、対応する OSGi 設定ファイル etc/PersistentID.cfg を作成するか、OSGi Config Admin Service によってサポートされる任意の設定方法を使用して直接編集できます。ただし、jaas:* コンソールのコマンドはサポートされません。

サポートされるクレデンシャル

JAAS OAGi 設定ログインモジュールはユーザー名/パスワードのクレデンシャルを認証し、認証されたユーザーに関連付けられたロールのリストを返します。

実装クラス

以下のクラスは JAAS OSGi 設定ログインモジュールを実装します。

org.apache.karaf.jaas.modules.osgi.OsgiConfigLoginModule
JAAS ログインモジュールを実装します。
注記

OSGi 設定ログインモジュールのバッキングエンジンファクトリーはありません。つまり、jaas:* コンソールコマンドを使用してこのモジュールを管理することはできません。

オプション

JAAS OSGi 設定ログインモジュールは、以下のオプションをサポートします。

pid
ユーザーデータが含まれる OSGi 設定の永続 ID。OSGi Config Admin 標準では、永続 ID は関連する設定プロパティーのセットを参照します。

設定ファイルの場所

設定ファイルの場所は、永続 ID PersistentID の設定が以下のファイルに保存される通常の慣例に従います。

InstallDir/etc/PersistentID.cfg

設定ファイルの形式

PersistentID.cfg 設定ファイルは、OSGi config ログインモジュールにユーザー名、パスワード、およびロールデータを保存するために使用されます。各ユーザーは、設定ファイルの 1 行で表現され、行は以下の形式になります。

Username=Password[,Role][,Role]...
注記

ユーザーグループは JAAS OSGi 設定ログインモジュールではサポートされません

Blueprint 設定の例

以下の Blueprint 設定は、OSGi 設定ログインモジュールを使用して新しい karaf レルムを定義する方法を示しています。ここで、rank 属性を 200 に設定すると、デフォルトの karaf レルムが上書きされます。

<?xml version="1.0" encoding="UTF-8"?>
<blueprint xmlns="http://www.osgi.org/xmlns/blueprint/v1.0.0"
  xmlns:jaas="http://karaf.apache.org/xmlns/jaas/v1.0.0"
  xmlns:cm="http://aries.apache.org/blueprint/xmlns/blueprint-cm/v1.1.0"
  xmlns:ext="http://aries.apache.org/blueprint/xmlns/blueprint-ext/v1.0.0">

  <jaas:config name="karaf" rank="200">
    <jaas:module flags="required"
className="org.apache.karaf.jaas.modules.osgi.OsgiConfigLoginModule">
        pid = org.jboss.example.osgiconfigloginmodule
    </jaas:module>
  </jaas:config>

</blueprint>

この例では、ユーザーデータはファイル InstallDir/etc/org.jboss.example.osgiconfigloginmodule.cfg に保存され、jaas:* コンソールを使用して設定を編集することはできません。

2.1.5. JAAS 公開鍵ログインモジュール

JAAS 公開鍵ログインモジュールは、単純なテキストエディターを使用して直接編集できるフラットファイル形式にユーザーデータを保存します。ただし、jaas:* コンソールのコマンドはサポートされません。

たとえば、Karaf コンテナーはデフォルトで JAAS 公開鍵ログインモジュールを使用し、関連するユーザーデータを InstallDir/etc/keys.properties ファイルに保存します。

サポートされるクレデンシャル

JAAS 公開鍵ログインモジュールは、SSH キーのクレデンシャルを認証します。ユーザーがログインしようとすると、SSH プロトコルは保存された公開鍵を使用してユーザーにチャレンジします。チャレンジに応答するには、ユーザーは対応する秘密鍵を所有している必要があります。ログインに成功すると、ログインモジュールはユーザーに関連付けられたロールのリストを返します。

実装クラス

以下のクラスは JAAS 公開鍵ログインモジュールを実装します。

org.apache.karaf.jaas.modules.publickey.PublickeyLoginModule
JAAS ログインモジュールを実装します。
注記

公開鍵ログインモジュールのバッキングエンジンファクトリーはありません。つまり、jaas:* コンソールコマンドを使用してこのモジュールを管理することはできません。

オプション

JAAS 公開鍵ログインモジュールは以下のオプションをサポートします。

users
公開鍵ログインモジュールのユーザープロパティーファイルの場所。

キープロパティーファイルの形式

keys.properties ファイルは、公開鍵ログインモジュールのユーザー名、公開鍵、およびロールデータを保存するために使用されます。各ユーザーはキープロパティーファイルの単一の行で表され、行は以下の形式になります。

Username=PublicKey[,UserGroup|Role][,UserGroup|Role]...

ここで PublicKey は、SSH キーペアの公開鍵の部分です (通常は UNIX システムの ~/.ssh/id_rsa.pub にあるユーザーのホームディレクトリーにあります) 。

たとえば、admin ロールでユーザー jdoe を作成するには、以下のようなエントリーを作成します。

jdoe=AAAAB3NzaC1kc3MAAACBAP1/U4EddRIpUt9KnC7s5Of2EbdSPO9EAMMeP4C2USZpRV1AIlH7WT2NWPq/xfW6MPbLm1Vs14E7gB00b/JmYLdrmVClpJ+f6AR7ECLCT7up1/63xhv4O1fnfqimFQ8E+4P208UewwI1VBNaFpEy9nXzrith1yrv8iIDGZ3RSAHHAAAAFQCXYFCPFSMLzLKSuYKi64QL8Fgc9QAAAnEA9+GghdabPd7LvKtcNrhXuXmUr7v6OuqC+VdMCz0HgmdRWVeOutRZT+ZxBxCBgLRJFnEj6EwoFhO3zwkyjMim4TwWeotifI0o4KOuHiuzpnWRbqN/C/ohNWLx+2J6ASQ7zKTxvqhRkImog9/hWuWfBpKLZl6Ae1UlZAFMO/7PSSoAAACBAKKSU2PFl/qOLxIwmBZPPIcJshVe7bVUpFvyl3BbJDow8rXfskl8wO63OzP/qLmcJM0+JbcRU/53Jj7uyk31drV2qxhIOsLDC9dGCWj47Y7TyhPdXh/0dthTRBy6bqGtRPxGa7gJov1xm/UuYYXPIUR/3x9MAZvZ5xvE0kYXO+rx,admin
重要

ここで、id_rsa.pub ファイルの内容をすべて挿入しないでください。公開鍵自体を表すシンボルのブロックのみを挿入します。

ユーザーグループはこのファイルで定義することもできます。このファイルで各ユーザーグループは、以下の形式で 1 行で表されます。

_g_\:GroupName=Role1[,Role2]...

Blueprint 設定の例

以下の Blueprint 設定は、公開鍵ログインモジュールを使用して新しい karaf レルムを定義する方法を示しています。ここで、rank 属性を 200 に設定すると、デフォルトの karaf レルムが上書きされます。

<?xml version="1.0" encoding="UTF-8"?>
<blueprint xmlns="http://www.osgi.org/xmlns/blueprint/v1.0.0"
  xmlns:jaas="http://karaf.apache.org/xmlns/jaas/v1.0.0"
  xmlns:cm="http://aries.apache.org/blueprint/xmlns/blueprint-cm/v1.1.0"
  xmlns:ext="http://aries.apache.org/blueprint/xmlns/blueprint-ext/v1.0.0">

<!--Allow usage of System properties, especially the karaf.base property-->
  <ext:property-placeholder
       placeholder-prefix="$[" placeholder-suffix="]"/>

  <jaas:config name="karaf" rank="200">
    <jaas:module flags="required"
className="org.apache.karaf.jaas.modules.publickey.PublickeyLoginModule">
        users = $[karaf.base]/etc/keys.properties
    </jaas:module>
  </jaas:config>

</blueprint>

この例では、ユーザーデータはファイル InstallDir/etc/keys.properties に保存され、jaas:* コンソールを使用して設定を編集することはできません。

2.1.6. JAAS JDBC ログインモジュール

概要

JAAS JDBC ログインモジュールを使用すると、Java Database Connectivity (JDBC) を使用してデータベースに接続し、データベースバックエンドにユーザーデータを保存できます。したがって、JDBC をサポートするデータベースを使用してユーザーデータを保存できます。ユーザーデータを管理するには、ネイティブデータベースクライアントツールまたは jaas:* コンソールコマンドのいずれかを使用できます (バッキングエンジンは設定済みの SQL クエリーを使用して関連データベースの更新を実行します) 。

複数のログインモジュールを各ログインモジュールと組み合わせて、認証コンポーネントと承認コンポーネントの両方を提供できます。たとえば、デフォルトの PropertiesLoginModuleJDBCLoginModule を組み合わせて、システムへのアクセスを確実にすることができます。

注記

ユーザーグループは JAAS JDBC ログインモジュールではサポートされません

サポートされるクレデンシャル

JAAS JDBC ログインモジュールはユーザー名/パスワードクレデンシャルを認証し、認証されたユーザーに関連するロールのリストを返します。

実装クラス

以下のクラスは JAAS JDBC ログインモジュールを実装します。

org.apache.karaf.jaas.modules.jdbc.JDBCLoginModule
JAAS ログインモジュールを実装します。
org.apache.karaf.jaas.modules.jdbc.JDBCBackingEngineFactory
OSGi サービスとして公開する必要があります。このサービスは、Apache Karaf シェルから jaas:* コンソールコマンドを使用してユーザーデータを管理できるようにします (『olink:FMQCommandRef/Consolejaas』を参照)。

オプション

JAAS JDBC ログインモジュールは以下のオプションをサポートします。

datasource

OSGi サービスまたは JNDI 名として指定された JDBC データソース。以下の構文を使用して、データソースの OSGi サービス を指定できます。

osgi:ServiceInterfaceName[/ServicePropertiesFilter]

ServiceInterfaceName は、データソースの OSGi サービス (通常は javax.sql.DataSource) によってエクスポートされるインターフェースまたはクラスです。

複数のデータソースは Karaf コンテナーで OSGi サービスとしてエクスポートできるため、通常はフィルター ServicePropertiesFilter を指定して必要な特定のデータソースを選択する必要があります。OSGi サービスのフィルターは、サービスプロパティー設定に適用され、LDAP フィルター構文から取り入れた構文に従います。

query.password
ユーザーのパスワードを取得する SQL クエリー。クエリーには 1 つの疑問符 ? を含めることができます。これは、実行時にユーザー名に置き換えられます。
query.role
ユーザーのロールを取得する SQL クエリー。クエリーには 1 つの疑問符 ? を含めることができます。これは、実行時にユーザー名に置き換えられます。
insert.user
新しいユーザーエントリーを作成する SQL クエリー。クエリーには 2 つの疑問符 ? を含めることができます。最初の疑問符はユーザー名に置き換えられ、2 つ目の疑問符は実行時にパスワードに置き換えられます。
insert.role
ロールをユーザーエントリーに追加する SQL クエリー。クエリーには 2 つの疑問符 ? を含めることができます。最初の疑問符はユーザー名に置き換えられ、2 つ目の疑問符は実行時にロールに置き換えられます。
delete.user
ユーザーエントリーを削除する SQL クエリー。クエリーには 1 つの疑問符 ? を含めることができます。これは、実行時にユーザー名に置き換えられます。
delete.role
ユーザーエントリーからロールを削除する SQL クエリー。クエリーには 2 つの疑問符 ? を含めることができます。最初の疑問符はユーザー名に置き換えられ、2 つ目の疑問符は実行時にロールに置き換えられます。
delete.roles
ユーザーエントリーから複数のロールを削除する SQL クエリー。クエリーには 1 つの疑問符 ? を含めることができます。これは、実行時にユーザー名に置き換えられます。

JDBC ログインモジュールの設定例

JDBC ログインモジュールを設定するには、以下の主要な手順を実行します。

データベーステーブルの作成

JDBC ログインモジュールを設定する前に、ユーザーデータを保存するために、バッキングデータベースにユーザーテーブルとロールテーブルを設定する必要があります。たとえば、以下の SQL コマンドは、適切な users テーブルと roles テーブルの作成方法を示しています。

CREATE TABLE users (
  username VARCHAR(255) NOT NULL,
  password VARCHAR(255) NOT NULL,
  PRIMARY KEY (username)
);
CREATE TABLE roles (
  username VARCHAR(255) NOT NULL,
  role VARCHAR(255) NOT NULL,
  PRIMARY KEY (username,role)
);

users テーブルにはユーザー名/パスワードデータが格納され、roles テーブルはユーザー名を 1 つ以上のロールに関連付けます。

データソースの作成

JDBC ログインモジュールで JDBC データソースを使用するには、データソースインスタンスを作成し、データソースを OSGi サービスとしてエクスポートするのが正しい方法です。エクスポートされた OSGi サービスを参照することで、JDBC ログインモジュールはデータソースにアクセスできます。たとえば、Blueprint ファイルに以下のようなコードを使用して、MySQL データソースインスタンスを作成し、OSGi サービス (javax.sql.DataSource 型) として公開できます。

<blueprint xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
           xmlns="http://www.osgi.org/xmlns/blueprint/v1.0.0">
  <bean id="mysqlDatasource"
        class="com.mysql.jdbc.jdbc2.optional.MysqlDataSource">
    <property name="serverName" value="localhost"></property>
    <property name="databaseName" value="DBName"></property>
    <property name="port" value="3306"></property>
    <property name="user" value="DBUser"></property>
    <property name="password" value="DBPassword"></property>
  </bean>

  <service id="mysqlDS" interface="javax.sql.DataSource"
        ref="mysqlDatasource">
    <service-properties>
        <entry key="osgi.jndi.service.name" value="jdbc/karafdb"/>
    </service-properties>
  </service>
</blueprint>

前述の Blueprint 設定は、OSGi バンドルとして Karaf コンテナーにパッケージ化およびインストールする必要があります。

データソースの OSGi サービスとしての指定

データソースが OSGi サービスとしてインスタンス化およびエクスポートされた後、JDBC ログインモジュールを設定する準備ができます。特に、JDBC ログインモジュールの datasource オプションは、以下の構文を使用してデータソースの OSGi サービスを参照できます。

osgi:javax.sql.DataSource/(osgi.jndi.service.name=jdbc/karafdb)

javax.sql.DataSource は、エクスポートされた OSGi サービスのインターフェースタイプで、フィルター (osgi.jndi.service.name=jdbc/karafdb) は、osgi.jndi.service.name サービスプロパティーの値が jdbc/karafdb の特定の javax.sql.DataSource インスタンスを選択します。

たとえば、以下の Blueprint 設定を使用して、サンプル MySQL データソースを参照する JDBC ログインモジュールで karaf レルムをオーバーライドできます。

<?xml version="1.0" encoding="UTF-8"?>
<blueprint xmlns="http://www.osgi.org/xmlns/blueprint/v1.0.0"
  xmlns:jaas="http://karaf.apache.org/xmlns/jaas/v1.0.0"
  xmlns:cm="http://aries.apache.org/blueprint/xmlns/blueprint-cm/v1.1.0"
  xmlns:ext="http://aries.apache.org/blueprint/xmlns/blueprint-ext/v1.0.0">

<!--Allow usage of System properties, especially the karaf.base property-->
  <ext:property-placeholder
       placeholder-prefix="$[" placeholder-suffix="]"/>

  <jaas:config name="karaf" rank="200">
    <jaas:module flags="required"
      className="org.apache.karaf.jaas.modules.jdbc.JDBCLoginModule">
        datasource = osgi:javax.sql.DataSource/(osgi.jndi.service.name=jdbc/karafdb)
        query.password = SELECT password FROM users WHERE username=?
        query.role = SELECT role FROM roles WHERE username=?
        insert.user = INSERT INTO users VALUES(?,?)
        insert.role = INSERT INTO roles VALUES(?,?)
        delete.user = DELETE FROM users WHERE username=?
        delete.role = DELETE FROM roles WHERE username=? AND role=?
        delete.roles = DELETE FROM roles WHERE username=?
    </jaas:module>
  </jaas:config>

  <!-- The Backing Engine Factory Service for the JDBCLoginModule -->
  <service interface="org.apache.karaf.jaas.modules.BackingEngineFactory">
    <bean class="org.apache.karaf.jaas.modules.jdbc.JDBCBackingEngineFactory"/>
  </service>

</blueprint>
注記

上記の設定に含まれる SQL ステートメントは、これらのオプションのデフォルト値です。したがって、これらの SQL ステートメントと一貫性のあるユーザーおよびロールテーブルを作成する場合は、オプション設定を省略し、デフォルトに依存することができます。

JDBCLoginModule を作成する他に、前述の Blueprint 設定も JDBCBackingEngineFactory インスタンスをインスタンス化し、エクスポートします。これにより、jaas:* コンソールコマンドを使用してユーザーデータを管理できます。

2.1.7. JAAS LDAP ログインモジュール

概要

JAAS LDAP ログインモジュールを使用すると、LDAP データベースにユーザーデータを保存できます。保存したユーザーデータを管理するには、標準の LDAP クライアントツールを使用します。jaas:* コンソールコマンドはサポートされません

Red Hat Fuse での LDAP の使用に関する詳細は、「LDAP Authentication Tutorial」を参照してください。

注記

ユーザーグループは JAAS LDAP ログインモジュールではサポートされません

サポートされるクレデンシャル

JAAS LDAP ログインモジュールはユーザー名/パスワードクレデンシャルを認証し、認証されたユーザーに関連するロールのリストを返します。

実装クラス

以下のクラスは JAAS LDAP ログインモジュールを実装します。

org.apache.karaf.jaas.modules.ldap.LDAPLoginModule
JAAS ログインモジュールを実装します。これは Karaf コンテナーに事前に読み込まれるため、そのバンドルをインストールする必要はありません。
注記

LDAP ログインモジュールのバッキングエンジンファクトリーはありません。つまり、jaas:* コンソールコマンドを使用してこのモジュールを管理することはできません。

オプション

JAAS LDAP ログインモジュールは以下のオプションをサポートします。

authentication

LDAP サーバーへバインドする時に使用される認証方法を指定します。有効な値は次のとおりです。

  • simple - ユーザー名とパスワード認証でバインドします。connection.username および connection.password プロパティーを設定する必要があります。
  • none - 匿名でバインドします。この場合、connection.username および connection.password プロパティーを割り当てする必要はありません。

    注記

    ディレクトリーサーバーへのコネクションは、検索の実行にのみ使用されます。この場合、認証されたバインドよりも高速な匿名バインドが優先されます (ただし、ファイアウォールの背後にデプロイするなど、ディレクトリーサーバーが十分に保護されていることを確認する必要もあります)。

connection.url

ldap URL、ldap://Host:Port を使用して、ディレクトリーサーバーの場所を指定します。オプションでこの URL を修飾するには、スラッシュ / とその後にディレクトリーツリーの特定ノードの DN を追加します。この接続で SSL セキュリティーを有効にするには、URL で ldaps: スキームを指定する必要があります (例: ldaps://Host:Port)。また、複数の URL をスペース区切りリストとして指定することもできます。以下に例を示します。

connection.url=ldap://10.0.0.153:2389 ldap://10.10.178.20:389
connection.username
ディレクトリーサーバーへの接続を開くユーザーの DN を指定します。例: uid=admin,ou=systemDN に空白文字が含まれる場合、LDAPLoginModule を解析できません。唯一の解決策は、空白が含まれる DN 名を二重引用符で囲み、引用符をエスケープ処理するためにバックスラッシュを追加することです。例: uid=admin,ou=\"system index\"
connection.password
connection.username からの DN と一致するパスワードを指定します。ディレクトリーサーバーでは通常、パスワードは対応するディレクトリーエントリーの userPassword 属性として保存されます。
context.com.sun.jndi.ldap.connect.pool
true の場合、LDAP 接続の接続プールを有効にします。デフォルトは false です。
context.com.sun.jndi.ldap.connect.timeout
LDAP サーバーへの TCP 接続を作成するためのタイムアウトをミリ秒単位で指定します。デフォルト値は無限であり、接続試行がハングする可能性があるため、このプロパティーを明示的に設定することが推奨されます。
context.com.sun.jndi.ldap.read.timeout
LDAP 操作の読み取りタイムアウトを指定します (ミリ秒単位) 。デフォルト値は無限であるため、このプロパティーを明示的に設定することが推奨されます。
context.java.naming.referral

LDAP 参照は、一部の LDAP サーバーでサポートされている間接的な形式です。LDAP 参照は、1 つ以上の URL が含まれる LDAP サーバー内のエントリーです (通常は別の LDAP サーバー内のノードを参照します)。context.java.naming.referral プロパティーを使用すると、フォローする参照を有効または無効にすることができます。以下の値のいずれかに設定できます。

  • follow、参照をフォローします (LDAP サーバーによってサポートされることを前提とします)。
  • ignore、すべての参照を通知せずに無視します。
  • throw、参照が発生するたびに PartialResultException をスローします。
disableCache
このプロパティーを true に設定すると、ユーザーおよびロールキャッシュを無効にできます。デフォルトは false です。
initial.context.factory
LDAP サーバーへの接続に使用されるコンテキストファクトリーのクラスを指定します。これは常に com.sun.jndi.ldap.LdapCtxFactory に設定する必要があります。
role.base.dn
ロールエントリーを検索する DIT のサブツリーの DN を指定します。例: ou=groups,ou=system
role.filter

ロールの検索に使用される LDAP 検索フィルターを指定します。これは、role.base.dn によって選択されるサブツリーに適用されます。例: (member=uid=%u)LDAP 検索操作に渡される前に、値は以下のように文字列置換の対象となります。

  • %u は、受信クレデンシャルから抽出されたユーザー名に置き換えられます。
  • %dn は、LDAP サーバーの対応するユーザーの RDN に置き換えられます (user.filter フィルターとの照合によって検出されます)。
  • %fqdn は、LDAP サーバーの対応するユーザーの DN に置き換えられます (user.filter フィルターとの照合によって検出されます)。
role.mapping

LDAP グループと JAAS ロール間のマッピングを指定します。マッピングが指定されていない場合、デフォルトのマッピングでは、各 LDAP グループが同じ名前の対応する JAAS ロールにマッピングされます。ロールマッピングは、以下の構文で指定されます。

ldap-group=jaas-role(,jaas-role)*(;ldap-group=jaas-role(,jaas-role)*)*

各 LDAP グループ ldap-group は Common Name (CN) によって指定されます。

たとえば、LDAP グループ admindevop、および tester の場合、以下のように JAAS ロールにマップできます。

role.mapping=admin=admin;devop=admin,manager;tester=viewer
role.name.attribute
ロール/グループの名前が含まれるロールエントリーの属性タイプを指定します。このオプションを省略すると、ロール検索機能は実質的に無効になります。例: cn
role.search.subtree
ロールエントリー検索範囲に、role.base.dn によって選択されたツリーのサブツリーが含まれるかどうかを指定します。true の場合、ロールの検索は再帰的 (SUBTREE) です。false の場合、ロールの検索は最初のレベル (ONELEVEL) でのみ実行されます。
ssl
SSL を使用して LDAP サーバーへの接続をセキュアにするかどうかを指定します。connection.urlldaps:// で始まる場合は、SSL がこのプロパティーに関係なく使用されます。
ssl.provider
LDAP 接続に使用する SSL プロバイダーを指定します。指定のない場合は、デフォルトの SSL プロバイダーが使用されます。
ssl.protocol
SSL 接続に使用するプロトコルを指定します。SSLv3 プロトコルが使用されないようにするには (POODLE 脆弱性)、このプロパティーを TLSv1 に設定する必要があります
ssl.algorithm
トラストストアマネージャーによって使用されるアルゴリズムを指定します。例: PKIX
ssl.keystore
LDAP クライアント独自の X.509 証明書を保存するキーストアの ID (LDAP サーバーで SSL クライアント認証が有効である場合にのみ必要)。キーストアは jaas:keystore 要素を使用してデプロイする必要があります (「Apache DS の設定例」 を参照)。
ssl.keyalias
LDAP クライアント独自の X.509 証明書のキーストアエイリアス (ssl.keystore によって指定されたキーストアに複数の証明書が保存される場合にのみ必要) 。
ssl.truststore
LDAP サーバーの証明書を検証するために使用される、信頼できる CA 証明書を保存するキーストアの ID (LDAP サーバーの証明書チェーンはトラストストアの証明書の 1 つで署名する必要があります)。キーストアは jaas:keystore 要素を使用してデプロイする必要があります。
user.base.dn
ユーザーエントリーを検索する DIT のサブツリーの DN を指定します。例: ou=users,ou=system
user.filter

ユーザークレデンシャルの検索に使用する LDAP 検索フィルターを指定します。これは、user.base.dn で選択されるサブツリーに適用されます。例: (uid=%u) LDAP 検索操作に渡される前に、値は以下のように文字列置換の対象となります。

  • %u は、受信クレデンシャルから抽出されたユーザー名に置き換えられます。
user.search.subtree
ユーザーエントリー検索範囲に、user.base.dn によって選択されたツリーのサブツリーが含まれるかどうかを指定します。true の場合、ユーザー検索は再帰的 (SUBTREE) になります。false の場合、ユーザーの検索は最初のレベル (ONELEVEL) でのみ実行されます。

Apache DS の設定例

以下の Blueprint 設定は、LDAP ログインモジュールを使用して新しい karaf レルムを定義する方法を示しています。ここで、rank 属性を 200 に設定すると、デフォルトの karaf レルムが上書きされ、LDAP ログインモジュールは Apache Directory Server に接続されます。

<?xml version="1.0" encoding="UTF-8"?>
<blueprint xmlns="http://www.osgi.org/xmlns/blueprint/v1.0.0"
  xmlns:jaas="http://karaf.apache.org/xmlns/jaas/v1.0.0"
  xmlns:cm="http://aries.apache.org/blueprint/xmlns/blueprint-cm/v1.1.0"
  xmlns:ext="http://aries.apache.org/blueprint/xmlns/blueprint-ext/v1.0.0">

  <jaas:config name="karaf" rank="100">

    <jaas:module className="org.apache.karaf.jaas.modules.ldap.LDAPLoginModule" flags="sufficient">
      debug=true

      <!-- LDAP Configuration -->
      initialContextFactory=com.sun.jndi.ldap.LdapCtxFactory
<!--  multiple LDAP servers can be specified as a space separated list of URLs -->
      connection.url=ldap://10.0.0.153:2389 ldap://10.10.178.20:389

<!--  authentication=none -->
      authentication=simple
      connection.username=cn=Directory Manager
      connection.password=directory

      <!-- User Info -->
      user.base.dn=dc=redhat,dc=com
      user.filter=(&amp;(objectClass=InetOrgPerson)(uid=%u))
      user.search.subtree=true

      <!-- Role/Group Info-->
      role.base.dn=dc=redhat,dc=com
      role.name.attribute=cn
<!--
      The 'dc=redhat,dc=com' used in the role.filter
      below is the user.base.dn.
-->
<!--      role.filter=(uniquemember=%dn,dc=redhat,dc=com) -->
      role.filter=(&amp;(objectClass=GroupOfUniqueNames)(UniqueMember=%fqdn))
      role.search.subtree=true

<!-- role mappings - a ';' separated list -->
      role.mapping=JBossAdmin=admin;JBossMonitor=viewer

<!-- LDAP context properties -->
      context.com.sun.jndi.ldap.connect.timeout=5000
      context.com.sun.jndi.ldap.read.timeout=5000

<!-- LDAP connection pooling -->
<!-- http://docs.oracle.com/javase/jndi/tutorial/ldap/connect/pool.html -->
<!-- http://docs.oracle.com/javase/jndi/tutorial/ldap/connect/config.html -->
     context.com.sun.jndi.ldap.connect.pool=true

<!-- How are LDAP referrals handled?

     Can be `follow`, `ignore` or `throw`.  Configuring `follow` may not work on all LDAP servers, `ignore` will
     silently ignore all referrals, while `throw` will throw a partial results exception if there is a referral.
-->
     context.java.naming.referral=ignore

<!-- SSL configuration -->
     ssl=false
     ssl.protocol=SSL
<!-- matches the keystore/truststore configured below -->
     ssl.truststore=ks
     ssl.algorithm=PKIX
<!-- The User and Role caches can be disabled - 6.3.0 179 and later -->
     disableCache=true
    </jaas:module>
  </jaas:config>

  <!-- Location of the SSL truststore/keystore
  <jaas:keystore name="ks" path="file:///${karaf.home}/etc/ldap.truststore" keystorePassword="XXXXXX" />
-->
</blueprint>
注記

SSL を有効にするには、connection.url 設定で ldaps スキームを使用する必要があります。

重要

Poodle 脆弱性 (CVE-2014-3566) から保護するには、ssl.protocolTLSv1 以降に設定する必要があります。

異なるディレクトリーサーバーのフィルター設定

ディレクトリーサーバー間の最も重要な違いは、LDAP ログインモジュールでフィルターオプションを設定することに関連しています。正確な設定は、最終的に DIT の組織によって異なりますが、次の表で異なるディレクトリーサーバーに必要な一般的なロールフィルター設定について説明します。

ディレクトリーサーバー一般的なフィルター設定

389-DS

Red Hat DS

user.filter=(&amp;(objectClass=InetOrgPerson)(uid=%u))
role.filter=(uniquemember=%fqdn)

MS Active Directory

user.filter=(&amp;(objectCategory=person)(samAccountName=%u))
role.filter=(uniquemember=%fqdn)

Apache DS

user.filter=(uid=%u)
role.filter=(member=uid=%u)

OpenLDAP

user.filter=(uid=%u)
role.filter=(member:=uid=%u)
注記

上記の表では、オプション設定が Blueprint XML ファイルに組み込まれるため、& 記号 (論理 And 演算子を表す) は &amp; としてエスケープ処理されます。

2.1.8. JAAS ログ監査ログインモジュール

ログインモジュール org.apache.karaf.jaas.modules.audit.LogAuditLoginModule は、認証試行の堅牢なロギングを提供します。これは、最大ファイルサイズ、ログローテーション、ファイル圧縮、フィルタリングの設定などの標準のログ管理機能をサポートします。このようなオプションをロギング設定ファイルで設定します。

デフォルトでは、認証監査ロギングは無効になっています。ロギングを有効にするには、ロギング設定と監査設定を定義した後、この 2 つをリンクする必要があります。ロギング設定では、ファイルアペンダープロセスおよびロガープロセスのプロパティーを指定します。ファイルアペンダーは、認証イベントに関する情報を指定されたファイルにパブリッシュします。ロガーは、認証イベントに関する情報をキャプチャーし、指定のアペンダーで使用できるようにするメカニズムです。標準の Karaf Log4j ロギング設定ファイル etc/org.ops4j.pax.logging.cfg でロギング設定を定義します。

監査設定により、監査ロギングが有効になり、使用されるロギングインフラストラクチャーにリンクします。監査設定は、etc/org.apache.karaf.jaas.cfg ファイルに定義します。

アペンダーの設定

デフォルトでは、標準の Karaf Log4j 設定ファイル (etc/org.ops4j.pax.logging.cfg) は、AuditRollingFile という名前の監査ロギングアペンダーを定義します。

次のサンプル設定ファイルの抜粋は、${karaf.data}/security/audit.log で監査ログファイルに書き込むアペンダーのプロパティーを示しています。

# Audit file appender
log4j2.appender.audit.type = RollingRandomAccessFile
log4j2.appender.audit.name = AuditRollingFile
log4j2.appender.audit.fileName = ${karaf.data}/security/audit.log
log4j2.appender.audit.filePattern = ${karaf.data}/security/audit.log.%i
log4j2.appender.audit.append = true
log4j2.appender.audit.layout.type = PatternLayout
log4j2.appender.audit.layout.pattern = ${log4j2.pattern}
log4j2.appender.audit.policies.type = Policies
log4j2.appender.audit.policies.size.type = SizeBasedTriggeringPolicy
log4j2.appender.audit.policies.size.size = 8MB

アペンダーを使用するには、ログファイルにパブリッシュするアペンダーの情報を提供するロガーを設定する必要があります。

ロガーの設定

デフォルトでは、Karaf Log4j 設定ファイル etc/org.ops4j.pax.logging.cfgorg.apache.karaf.jaas.modules.audit という名前の監査ロガーを確立します。次のサンプル設定ファイルの抜粋では、認証イベントに関する情報を、AuditRollingFile という名前のアペンダーに提供するようにデフォルトロガーが設定されています。

log4j2.logger.audit.name = org.apache.karaf.jaas.modules.audit
log4j2.logger.audit.level = INFO
log4j2.logger.audit.additivity = false
log4j2.logger.audit.appenderRef.AuditRollingFile.ref = AuditRollingFile

log4j2.logger.audit.appenderRef.AuditRollingFile.ref の値は、etc/org.ops4j.pax.logging.cfgAudit file appender セクションにある log4j2.appender.audit.name の値に一致する必要があります。

2.1.8.1. 認証監査ロギングの有効化

ロギング設定を設定したら、監査ロギングを有効にし、ロギング設定を監査設定に接続できます。

監査ロギングを有効にするには、etc/org.apache.karaf.jaas.cfg に以下の行を挿入します。

audit.log.enabled = true
audit.log.logger = <logger.name>
audit.log.level = <level>

<logger.name> は、org.jboss.fuse.auditcom.example.audit など、Apache Log4J ライブラリーと Log4J2 ライブラリーによって確立される標準のロガー (カテゴリー) 名のドット区切り形式を表します。<level>` は、WARNINFOTRACE、または DEBUG などのログレベル設定を表します。

たとえば、以下のサンプル監査設定ファイルにある以下の抜粋で、監査ログが有効になり、org.apache.karaf.jaas.modules.audit という名前の監査ロガーを使用するように設定されます。

audit.log.enabled = true
audit.log.logger = org.apache.karaf.jaas.modules.audit
audit.log.level = INFO

audit.log.logger の値は、Karaf Log4j 設定ファイル (etc/org.ops4j.pax.logging.cfg) の log4j2.logger.audit.name の値と一致する必要があります。

ファイルの更新後、Apache Felix File Install バンドルが変更を検出し、Apache Felix Configuration Service (Config Admin) で設定を更新します。その後、Config Admin の設定はロギングインフラストラクチャーに渡されます。

設定ファイルを更新する Apache Karaf シェルコマンド

<FUSE_HOME>/etc の設定ファイルは直接編集するか、Apache Karaf config:* コマンドを実行して、Config Admin を更新できます。

config* コマンドを使用して設定を更新すると、Apache Felix File Install バンドルは変更について通知され、関連する etc/*.cfg ファイルが自動的に更新されます。

例: config コマンドを使用した JAAS レルムのプロパティーの一覧表示

シェルプロンプトから JAAS レルムのプロパティーをリストするには、以下のコマンドを入力します。

config:property-list --pid org.apache.karaf.jaas

このコマンドは、レルムの現在のプロパティーを返します。以下に例を示します。

   audit.log.enabled = true
   audit.log.level = INFO
   audit.log.logger = org.apache.karaf.jaas.modules.audit
   encryption.algorithm = MD5
   encryption.enabled = false
   encryption.encoding = hexadecimal
   encryption.name =
   encryption.prefix = {CRYPT}
   encryption.suffix = {CRYPT}

例: config コマンドを使用した監査ログレベルの変更

レルムの監査ログレベルを DEBUG に変更するには、シェルプロンプトでコマンド config:property-set --pid org.apache.karaf.jaas audit.log.level DEBUG を実行します。

変更が有効であることを確認するには、再度プロパティーをリストして、audit.log.level の値を確認します。

2.1.9. JAAS ファイル監査ログインモジュール

認証モジュール org.apache.karaf.jaas.modules.audit.FileAuditLoginModule は、認証試行の基本ロギングを提供します。ファイル監査ログインモジュールは、指定したファイルに直接書き込みます。Pax ロギングインフラストラクチャーに依存しないため、設定はシンプルです。しかし、ログ監査ログインモジュールとは異なり、パターンのフィルタリング、ログファイルのローテーションなどのログ管理機能はサポートされません。

FileAuditLoginModule で監査ロギングを有効にするには、etc/org.apache.karaf.jaas.cfg に以下の行を挿入します。

audit.file.enabled = true
audit.file.file = ${karaf.data}/security/audit.log
注記

通常、ファイル監査ログインモジュールログ監査ログインモジュールの両方を使用して監査ロギングを設定しません。両方のモジュールでロギングを有効にする場合は、各モジュールが一意のターゲットログファイルを使用するように設定することで、データの損失を回避できます。

2.1.10. 保存されたパスワードの暗号化

デフォルトでは、JAAS ログインモジュールはパスワードをプレーンテキスト形式で保存します。ファイルのパーミッションを適切に設定することで、このようなデータを保護することはできますが (できる必要があります)、あいまいな形式でパスワードを保存することで (メッセージダイジェストアルゴリズムを使用して)、パスワードの保護を強化できます。

Red Hat Fuse は、パスワード暗号化を有効にするためのオプションを提供します。これはあらゆる JAAS ログインモジュールと組み合わせることができます (不必要な場合の公開鍵ログインモジュールを除く)。

重要

メッセージダイジェストアルゴリズムの解読は困難ですが、攻撃の影響を受けないわけではありません (例は Wikipedia の暗号ハッシュ関数に関する記事を参照)。パスワード暗号化を使用するだけでなく、パスワードが含まれるファイルを保護するために常にファイル権限を使用してください。

オプション

必要に応じて以下のログインモジュールプロパティーを設定して、JAAS ログインモジュールのパスワード暗号化を有効にできます。これには、「Jasypt 暗号化を使用したログインモジュールの例」 の説明に従って InstallDir/etc/org.apache.karaf.jaas.cfg ファイルを編集するか、または独自の Blueprint ファイルをデプロイします。

encryption.enabled
パスワード暗号化を有効にするには、true に設定します。
encryption.name
OSGi サービスとして登録された暗号化サービスの名前。
encryption.prefix
暗号化されたパスワードのプレフィックス
encryption.suffix
暗号化されたパスワードのサフィックス
encryption.algorithm

暗号化アルゴリズムの名前を指定します (例: MD5 または SHA-1)。以下の暗号化アルゴリズムのいずれかを指定できます。

  • MD2
  • MD5
  • SHA-1
  • SHA-256
  • SHA-384
  • SHA-512
encryption.encoding
暗号化されたパスワードエンコーディング: hexadecimal または base64
encryption.providerName (Jasypt のみ)
ダイジェストアルゴリズムを提供する java.security.Provider インスタンスの名前。
encryption.providerClassName (Jasypt のみ)
ダイジェストアルゴリズムを提供するセキュリティープロバイダーのクラス名
encryption.iterations (Jasypt のみ)
ハッシュ関数を再帰的に適用する回数。
encryption.saltSizeBytes (Jasypt のみ)
ダイジェストの計算に使用される salt のサイズ。
encryption.saltGeneratorClassName (Jasypt のみ)
salt ジェネレーターのクラス名。
role.policy
ロールプリンシパルを識別するためのポリシーを指定します。prefix または group の値を指定できます。
role.discriminator
ロールポリシーによって使用される識別子の値を指定します。

暗号化サービス

Fuse が提供する暗号化サービスは 2 つあります。

独自の暗号化サービスを作成することもできます。これを実行するには、以下が必要です。

  • org.apache.karaf.jaas.modules.EncryptionService インターフェースを実装する。
  • 実装を OSGI サービスとして公開する。

以下のリストは、カスタム暗号化サービスを OSGI コンテナーに公開する方法を示しています。

<blueprint xmlns="http://www.osgi.org/xmlns/blueprint/v1.0.0">

    <service interface="org.apache.karaf.jaas.modules.EncryptionService">
        <service-properties>
            <entry key="name" value="jasypt" />
        </service-properties>
        <bean class="org.apache.karaf.jaas.jasypt.impl.JasyptEncryptionService"/>
    </service>
    ...
</blueprint>

Basic 暗号化サービス

Basic 暗号化サービスは、デフォルトで Karaf コンテナーにインストールされ、encryption.name プロパティーを basic という値に設定することで参照が可能です。Basic 暗号化サービスでは、メッセージダイジェストアルゴリズムは SUN セキュリティープロバイダー (Oracle JDK のデフォルトのセキュリティープロバイダー) によって提供されます。

Jasypt 暗号化

通常、Jasypt 暗号化サービスはデフォルトで Karaf にインストールされます。必要に応じて、以下のように jasypt-encryption 機能をインストールして明示的にインストールできます。

JBossA-MQ:karaf@root> features:install jasypt-encryption

このコマンドは、必要な Jasypt バンドルをインストールし、Jasypt 暗号化を OSGi サービスとしてエクスポートし、JAAS ログインモジュールで使用できるようにします。

Jasypt 暗号化の詳細は、Jasypt のドキュメントを参照してください。

Jasypt 暗号化を使用したログインモジュールの例

デフォルトでは、パスワードは etc/users.properties ファイルにクリアテキストで保存されます。jasypt-encryption 機能をインストールし、etc/org.apache.karaf.jaas.cfg 設定ファイルを変更することで、暗号化を有効にできます。

  1. 機能 jasypt-encryption をインストールします。これにより、jasypt サービスがインストールされます。

    karaf@root> features:install jasypt-encryption

    これで、jaas コマンドを使用してユーザーを作成できます。

  2. $FUSE_HOME/etc/org.apache.karaf.jaas.cfg ファイルを開き、以下のように変更します。encryption.enabled = trueencryption.name = jasypt、およびこの場合は encryption.algorithm = SHA-256 を設定します。その他の encryption.algorithm オプションは、要件に応じて設定できます。

    #
    # Boolean enabling / disabling encrypted passwords
    #
    encryption.enabled = true
    
    #
    # Encryption Service name
    #   the default one is 'basic'
    #   a more powerful one named 'jasypt' is available
    #       when installing the encryption feature
    #
    encryption.name = jasypt
    
    #
    # Encryption prefix
    #
    encryption.prefix = {CRYPT}
    
    #
    # Encryption suffix
    #
    encryption.suffix = {CRYPT}
    
    #
    # Set the encryption algorithm to use in Karaf JAAS login module
    # Supported encryption algorithms follow:
    #   MD2
    #   MD5
    #   SHA-1
    #   SHA-256
    #   SHA-384
    #   SHA-512
    #
    encryption.algorithm = SHA-256
  3. Karaf コンソールで jaas:realms コマンドを入力し、デプロイされたログインモジュールを表示します。

    karaf@root()> jaas:realms
    
    Index │ Realm Name │ Login Module Class Name
    
    ──────┼────────────┼───────────────────────────────────────────────────────────────
    
    1     │ karaf      │ org.apache.karaf.jaas.modules.properties.PropertiesLoginModule
    
    2     │ karaf      │ org.apache.karaf.jaas.modules.publickey.PublickeyLoginModule
    
    3     │ karaf      │ org.apache.karaf.jaas.modules.audit.FileAuditLoginModule
    
    4     │ karaf      │ org.apache.karaf.jaas.modules.audit.LogAuditLoginModule
    
    5     │ karaf      │ org.apache.karaf.jaas.modules.audit.EventAdminAuditLoginModule
  4. 以下のコマンドを実行してユーザーを作成します。

    karaf@root()> jaas:realm-manage --index 1
    
    karaf@root()> jaas:user-list
    
    User Name │ Group      │ Role
    
    ──────────┼────────────┼──────────────
    
    admin     │ admingroup │ admin
    
    admin     │ admingroup │ manager
    
    admin     │ admingroup │ viewer
    
    admin     │ admingroup │ systembundles
    
    admin     │ admingroup │ ssh
    
    karaf@root()> jaas:useradd usertest test123
    
    karaf@root()> jaas:group-add usertest admingroup
    
    karaf@root()> jaas:update
    
    karaf@root()> jaas:realm-manage --index 1
    
    karaf@root()> jaas:user-list
    
    User Name │ Group      │ Role
    
    ──────────┼────────────┼──────────────
    
    admin     │ admingroup │ admin
    
    admin     │ admingroup │ manager
    
    admin     │ admingroup │ viewer
    
    admin     │ admingroup │ systembundles
    
    admin     │ admingroup │ ssh
    
    usertest  │ admingroup │ admin
    
    usertest  │ admingroup │ manager
    
    usertest  │ admingroup │ viewer
    
    usertest  │ admingroup │ systembundles
    
    usertest  │ admingroup │ ssh
  5. ここで、$FUSE_HOME/etc/users.properties ファイルを確認すると、ユーザー usertest がファイルに追加されたことが確認できます。

    admin = {CRYPT}WXX+4PM2G7nT045ly4iS0EANsv9H/VwmStGIb9bcbGhFH5RgMuL0D3H/GVTigpga{CRYPT},_g_:admingroup
    
    _g_\:admingroup = group,admin,manager,viewer,systembundles,ssh
    
    usertest = {CRYPT}33F5E76E5FF97F3D27D790AAA1BEE36057410CCDBDBE2C792239BB2853D17654315354BB8B608AD5{CRYPT},_g_:admingroup
  6. 既に jaas:update コマンドを実行しているので、新たに作成したログインを別のターミナルでテストできます。

2.1.11. HTTP Basic 認証による JAAS インテグレーション

Servlet REST を使用して、REST DSL を使用する Camel ルートに REST エンドポイントを定義できます。以下の例は、HTTP Basic 認証によって保護される REST エンドポイントが Karaf JAAS サービスにユーザー認証を委譲する方法を示しています。

手順

  1. Apache Camel を CamelInstallDir にインストールした場合、以下のディレクトリーでサンプルを見つけることができます。

    CamelInstallDir/examples/camel-example-servlet-rest-karaf-jaas
  2. Maven を使用してサンプルを OSGi バンドルとしてビルドおよびインストールします。コマンドプロンプトを開き、現在のディレクトリーを CamelInstallDir/examples/camel-example-servlet-rest-karaf-jaas に切り替えて、以下のコマンドを入力します。

    mvn install
  3. セキュリティー設定ファイルを KARAF_HOME/etc フォルダーにコピーするには、以下のコマンドを入力します。

    cp src/main/resources/org.ops4j.pax.web.context-camelrestdsl.cfg $KARAF_HOME/etc
  4. Karaf に Apache Camel をインストールするには、Karaf シェルコンソールで以下のコマンドを入力します。

    feature:repo-add camel ${project.version}
    feature:install camel
  5. camel-servletcamel-jackson、および war Karaf 機能も必要で、以下のコマンドを入力してこれらの機能をインストールします。

    feature:install camel-servlet
    feature:install camel-jackson
    feature:install war
  6. camel-example-servlet-rest-karaf-jaas サンプルをインストールするには、以下のコマンドを入力します。

    install -s mvn:org.apache.camel.example/camel-example-servlet-rest-karaf-jaas/${project.version}

結果

アプリケーションが実行中であることを確認するには、以下のコマンドを入力してアプリケーションログファイルを表示できます (ログの表示を停止する場合はctrl+c を使用)。

log:tail

REST user エンドポイントは、以下の操作をサポートします。

  • GET /user/{id} - 指定 ID を持つユーザーを表示します。
  • GET /user/final - すべてのユーザーを表示します。
  • PUT /user - ユーザーを更新/作成します。
注記

view 操作は HTTP GET を使用し、update 操作は HTTP PUT を使用します。

2.1.11.1. Web ブラウザーからの REST サービスへのアクセス

以下の例を使用して、Web ブラウザーからサービスにアクセスできます (admin をユーザー、admin をパスワードとしてポップアップダイアログボックスに入力する必要があります)。

例: ユーザー ID 123 の表示

http://localhost:8181/camel-example-servlet-rest-blueprint/rest/user/123

例: 全ユーザーの一覧表示

http://localhost:8181/camel-example-servlet-rest-blueprint/rest/user/findAll

2.1.11.2. コマンドラインからの REST サービスへのアクセス

以下の例のように、コマンドラインから curl を使用して REST user エンドポイントにアクセスできます。

例: ユーザー ID 123 の表示

curl -X GET -H "Accept: application/json" --basic -u admin:admin http://localhost:8181/camel-example-servlet-rest-blueprint/rest/user/123

例: 全ユーザーの表示

curl -X GET -H "Accept: application/json" --basic -u admin:admin http://localhost:8181/camel-example-servlet-rest-blueprint/rest/user/findAll

例: ユーザー ID 234 の作成または更新

curl -X PUT -d "{ \"id\": 234, \"name\": \"John Smith\"}" -H "Accept: application/json" --basic -u admin:admin http://localhost:8181/camel-example-servlet-rest-blueprint/rest/user

2.2. ロールベースアクセス制御

概要

本セクションでは、Karaf コンテナーでデフォルトで有効になっているロールベースアクセス制御 (RBAC) 機能について説明します。標準のロール (manageradmin など) をユーザーのクレデンシャルに追加すると、すぐに RBAC 機能を活用できます。さらに高度な使用方法として、各ロールの権限を正確に制御するために、アクセス制御リストを必要に応じてカスタマイズすることができます。最後に、必要に応じて、カスタム ACL を独自の OSGi サービスに適用できます。

2.2.1. ロールベースアクセス制御の概要

デフォルトでは、Fuse のロールベースアクセス制御は、Fuse Management Console、JMX コネクション、および Karaf コマンドコンソールを介してアクセスを保護します。デフォルトのアクセス制御レベルを使用するには、ユーザー認証データに標準ロールを追加します (例: users.properties ファイルを編集して)。関連するアクセス制御リスト (ACL) ファイルを編集して、アクセス制御をカスタマイズすることもできます。

メカニズム

Karaf のロールベースアクセス制御は、以下のメカニズムに基づいています。

JMX ガード
Karaf コンテナーは JMX ガードで設定されています。JMX ガードはすべての受信 JMX 呼び出しをインターセプトし、設定された JMX アクセス制御リストを介して呼び出しをフィルタリングします。JMX ガードは JVM レベルで設定されるため、例外なくすべての JMX 呼び出しをインターセプトします。
OSGi サービスガード
OSGi サービスでは、OSGi サービスガードを設定できます。OSGi サービスガードは、プロキシーオブジェクトとして実装され、クライアントと元の OSGi サービスとの間に置かれます。OSGi サービスガードは、各 OSGi サービスに対して明示的に設定する必要があります。デフォルトではインストールされません (事前設定されている Karaf コンソールコマンドを表す OSGi サービスを除く) 。

保護の種類

ロールベースアクセス制御の Fuse 実装は、以下の種類の保護を提供できます。

Fuse Console (Hawtio)
Fuse Console (Hawtio) 経由のコンテナーアクセスは、JMX ACL ファイルによって制御されます。Fuse Console を提供する REST/HTTP サービスは、JMX の上に階層化された Jolokia の技術を使用して実装されます。そのため、最終的にすべての Fuse Console 呼び出しは JMX を通過し、JMX ACL によって規制されます。
JMX
Karaf コンテナーの JMX ポートへの直接アクセスは、JMX ACL によって規制されます。さらに、JMX レベルで JMX ガードが設定されるため、Karaf コンテナーで実行しているアプリケーションによって開かれる追加の JMX ポートも JMX ACL によって規制されます。
Karaf コマンドコンソール

Karaf コマンドコンソールへのアクセスは、コマンドコンソールの ACL ファイルによって規制されます。アクセス制御は、Karaf コンソールへのアクセス方法に関係なく適用されます。Fuse Console または SSH プロトコル経由でコマンドコンソールにアクセスする場合、アクセス制御はどちらの場合にも適用されます。

注記

コマンドラインで Karaf コンテナーを直接起動し (./bin/fuse スクリプトを使用するなどして)、ユーザー認証が実行されない特別なケースでは、etc/system.properties ファイルの karaf.local.roles プロパティーで指定されたロールを自動的に取得します。

OSGi サービス
Karaf コンテナーにデプロイされた OSGi サービスでは、任意で ACL ファイルを有効にできます。これにより、メソッド呼び出しを特定のロールに制限することができます。

ロールのユーザーへの追加

ロールベースアクセス制御のシステムでは、ユーザー認証データにロールを追加して、ユーザーにパーミッションを付与できます。たとえば、etc/users.properties ファイルの以下のエントリーは admin ユーザーを定義し、admin ロールを付与します。

admin = secretpass,group,admin,manager,viewer,systembundles,ssh

また、ユーザーグループを定義し、ユーザーを特定のユーザーグループに割り当てることもできます。たとえば、以下のように admingroup ユーザーグループを定義および使用できます。

admin = secretpass, _g_:admingroup

_g_\:admingroup = group,admin,manager,viewer,systembundles,ssh
注記

ユーザーグループは、すべてのタイプの JAAS ログインモジュールでサポートされるわけではありません。

標準ロール

表2.2「アクセス制御の標準ロール」 に、JMX ACL およびコマンドコンソール ACL 全体で使用される標準ロールの一覧と説明を示します。

表2.2 アクセス制御の標準ロール

ロール説明

viewer

Karaf コンテナーへの読み取り専用アクセスを付与します。

manager

アプリケーションをデプロイおよび実行する通常のユーザーに、適切なレベルで読み書きアクセスを付与します。ただし、機密性の高い Karaf コンテナー設定へのアクセスはブロックされます。

admin

Karaf コンテナーへの無制限のアクセスを付与します。

ssh

Karaf コマンドコンソール (ssh ポートから) に接続するパーミッションをユーザーに付与します。

ACL ファイル

標準的な ACL ファイルは、以下のように Fuse インストールの etc/auth/ ディレクトリーにあります。

etc/auth/jmx.acl[.*].cfg
JMX ACL ファイル。
etc/auth/org.apache.karaf.command.acl.*.cfg
コマンドコンソールの ACL ファイル。

ロールベースアクセス制御のカスタマイズ

JMX ACL ファイルおよびコマンドコンソールの ACL ファイルの完全なセットはデフォルトで提供されます。システムの要件に応じて、これらの ACL を自由にカスタマイズできます。これを行う方法の詳細については、後続のセクションで説明します。

アクセスを制御するための追加プロパティー

etc ディレクトリーの system.properties ファイルには、Karaf コマンドコンソールおよび Fuse Console (Hawtio) を介してアクセスを制御する以下の追加プロパティーが提供されます。

karaf.local.roles
ユーザーが Karaf コンテナーコンソールをローカルで起動する際に適用するロールを指定します (スクリプトを実行するなどして)。
hawtio.roles
Fuse Console から Karaf コンテナーへのアクセスを許可するロールを指定します。この制約は、JMX ACL ファイルによって定義されるアクセス制御に加えて適用されます。
karaf.secured.command.compulsory.roles
コンソールコマンドが etc/auth/org.apache.karaf.command.acl.*.cfg コマンド ACL ファイルによって明示的に設定されていない場合に、Karaf コンソールコマンドの呼び出しに必要なデフォルトのロールを指定します。コマンドを呼び出すには、リストから少なくとも 1 つのロールを使用してユーザーを設定する必要があります。この値は、ロールのカンマ区切りリストとして指定されます。

2.2.2. JMX ACL のカスタマイズ

JMX ACL は OSGi Config Admin Service に保存され、通常はファイル etc/auth/jmx.acl.*.cfg としてアクセスできます。本セクションでは、これらのファイルを編集して JMX ACL をカスタマイズする方法を説明します。

アーキテクチャー

図2.1「JMX のアクセス制御メカニズム」 では、Karaf コンテナーへの JMX コネクションのロールベースアクセス制御メカニズムの概要を示しています。

図2.1 JMX のアクセス制御メカニズム

rbac 01

仕組み

JMX アクセス制御は、特別な javax.management.MBeanServer オブジェクトを介して JMX へのリモートアクセスを提供することで動作します。このオブジェクトは、JMX ガードと呼ばれる org.apache.karaf.management.KarafMBeanServerGuard オブジェクトを呼び出して、プロキシーとして機能します。JMX ガードは、起動ファイルに特別な設定なしで利用できます。

JMX アクセス制御は、以下のように適用されます。

  1. ローカルでない JMX 呼び出しごとに、実際の MBean 呼び出しの前に JMX ガードが呼び出されます。
  2. JMX ガードは、ユーザーがアクセスしようとしている MBean の関連する ACL を検索します (ACL は OSGi Config Admin サービスに保存されます)。
  3. ACL は、MBean でこの特定の呼び出しを実行できるロールのリストを返します。
  4. JMX ガードは、現在のセキュリティーサブジェクト (JMX 呼び出しを行ったユーザー) に対してロールのリストをチェックし、現在のユーザーに必要なロールがあるかどうかを調べます。
  5. 一致するロールが見つからない場合、JMX 呼び出しがブロックされ、SecurityException が発生します。

JMX ACL ファイルの場所

JMX ACL ファイルは InstallDir/etc/auth ディレクトリーにあります。ACL ファイルの名前は次の命名規則に従います。

etc/auth/jmx.acl[.*].cfg

技術的には、ACL は、パターン jmx.acl[.*] と一致する OSGi 永続 ID (PID) にマッピングされます。Karaf コンテナーは、デフォルトで OSGi PID をファイル PID.cfg として etc/ ディレクトリー内に保存します。

MBean の ACL ファイル名へのマッピング

JMX ガードは、JMX 経由でアクセスされるすべての MBean クラスにアクセス制御を適用します (独自のアプリケーションコードに定義する MBean を含む)。特定の MBean クラスの ACL ファイルは、jmx.acl をプレフィックスとして追加して、MBean のオブジェクト名から派生します。たとえば、オブジェクト名が org.apache.camel:type=context によって付与される MBean の場合、対応する PID は以下のようになります。

jmx.acl.org.apache.camel.context

OSGi Config Admin サービスは、この PID データを以下のファイルに保存します。

etc/auth/jmx.acl.org.apache.camel.context.cfg

ACL ファイルフォーマット

JMX ACL ファイルの各行は、以下の形式のエントリーです。

Pattern = Role1[,Role2][,Role3]...

Pattern は、MBean のメソッド呼び出しと一致するパターンで、等号記号の右側は、その呼び出しを行う権限をユーザーに付与するロールのカンマ区切りリストです。最も単純なケースでは、Pattern は単にメソッド名です。たとえば、jmx.acl.hawtio.OSGiTools MBean の以下の設定 (jmx.acl.hawtio.OSGiTools.cfg ファイルからの) です。

getResourceURL = admin, manager, viewer
getLoadClassOrigin = admin, manager, viewer

また、複数のメソッド名と一致するためにワイルドカード文字 * を使用することもできます。たとえば、以下のエントリーは、名前が set で始まるすべてのメソッドを呼び出す権限を付与します。

set* = admin, manager, viewer

ただし、ACL 構文は、メソッド呼び出しのより細かな制御を定義することもできます。特定の引数や、正規表現に一致する引数で呼び出されたメソッドと一致するパターンを定義できます。たとえば、org.apache.karaf.config MBean パッケージの ACL はこの機能を利用して、通常のユーザーが機密性の高い設定を変更できないようにします。このパッケージの create メソッドは、以下のように制限されます。

create(java.lang.String)[/jmx[.]acl.*/] = admin
create(java.lang.String)[/org[.]apache[.]karaf[.]command[.]acl.+/] = admin
create(java.lang.String)[/org[.]apache[.]karaf[.]service[.]acl.+/] = admin
create(java.lang.String) = admin, manager

この場合、manager ロールには、通常 create メソッドを呼び出す権限がありますが、admin ロールのみが jmx.acl.*org.apache.karaf.command.acl.*、または org.apache.karaf.service.* に一致する PID 引数で create を呼び出す権限を持ちます。

ACL ファイル形式の完全な詳細は、etc/auth/jmx.acl.cfg ファイルのコメントを参照してください。

ACL ファイル階層

すべての MBean に ACL ファイルを提供することは現実的ではないことが多いため、Java パッケージのレベルで ACL ファイルを指定するオプションがあります。これにより、そのパッケージのすべての MBean のデフォルト設定が提供されます。たとえば、org.apache.cxf.Bus MBean は、以下の PID レベルのいずれかで ACL 設定による影響を受ける可能性があります。

jmx.acl.org.apache.cxf.Bus
jmx.acl.org.apache.cxf
jmx.acl.org.apache
jmx.acl.org
jmx.acl

ここで、最も具体的な PID (リストの上部) は、最も具体的でない PID (リストの下部) よりも優先されます。

ルート ACL 定義

ルート ACL ファイル jmx.acl.cfg は、すべての MBean に対してデフォルトの ACL 設定を提供するため、特別なケースです。ルート ACL には、デフォルトで以下の設定があります。

list* = admin, manager, viewer
get* = admin, manager, viewer
is* = admin, manager, viewer
set* = admin
* = admin

これは、典型的な読み取りメソッドパターン (list*get*is*) はすべての標準ロールにアクセスでき、通常の 書き込み メソッドパターンおよびその他のメソッド (set* および \*) は admin ロール (admin) のみにアクセスできる事を意味します。

パッケージ ACL の定義

etc/auth/jmx.acl[.*].cfg で提供される標準の JMX ACL ファイルの多くは MBean パッケージに適用されます。たとえば、org.apache.camel.endpoints MBean パッケージの ACL は以下のパーミッションで定義されます。

is* = admin, manager, viewer
get* = admin, manager, viewer
set* = admin, manager

カスタム MBean の ACL

独自のアプリケーションでカスタム MBean を定義すると、これらのカスタム MBean は自動的に ACL メカニズムと統合され、Karaf コンテナーにデプロイするときに JMX ガードによって保護されます。ただしデフォルトでは、通常 MBean はデフォルトのルート ACL ファイル jmx.acl.cfg によってのみ保護されます。MBean に対してより細かな ACL を定義する場合は、標準の JMX ACL ファイルの命名規則を使用して、etc/auth 下に新しい ACL ファイルを作成します。

たとえば、カスタム MBean クラスに JMX オブジェクト名 org.example:type=MyMBean がある場合は、etc/auth ディレクトリー下に以下の名前を持つ新しい ACL ファイルを作成します。

jmx.acl.org.example.MyMBean.cfg

起動時の動的な設定

OSGi Config Admin サービスは動的であるため、システムの実行中に ACL 設定を変更できます。また、特定のユーザーがログインしている間でも、ACL 設定を変更できます。したがって、システムの実行中にセキュリティー違反を検出すると、Karaf コンテナーを再起動しなくても関連する ACL ファイルを編集して、システムの特定の部分へのアクセスをすぐに制限できます。

2.2.3. コマンドコンソール ACL のカスタマイズ

コマンドコンソール ACL は OSGi Config Admin Service に保存され、通常はファイル etc/auth/org.apache.karaf.command.acl.*.cfg としてアクセスできます。本セクションでは、これらのファイルを編集してコマンドコンソール ACL をカスタマイズする方法を説明します。

アーキテクチャー

図2.2「OSGi サービスのアクセス制御メカニズム」 は、Karaf コンテナーにおける OSGi サービスのロールベースアクセス制御メカニズムの概要を示しています。

図2.2 OSGi サービスのアクセス制御メカニズム

rbac 02

仕組み

実際には、コマンドコンソールのアクセス制御のメカニズムは、OSGi サービスの汎用アクセス制御メカニズムに基づいています。コンソールコマンドは OSGi サービスとして実装および公開されます。Karaf コンソール自体は OSGi サービスレジストリーを介して利用可能なコマンドを検出し、OSGi サービスとしてコマンドにアクセスします。そのため、OSGi サービスのアクセス制御メカニズムを使用して、コンソールコマンドへのアクセスを制御できます。

OSGi サービスを保護するためのメカニズムは、OSGi Service Registry Hooks に基づいています。これは、特定のコンシューマーから OSGi サービスを隠し、OSGi サービスをプロキシーサービスに置き換えることができる高度な OSGi 機能です。

特定の OSGi サービスに対してサービスガードが配置されていると、OSGi サービス上のクライアント呼び出しは次のように続行されます。

  1. 呼び出しは、要求された OSGi サービスに直接送信されません。代わりに、リクエストは代替プロキシーサービスにルーティングされます。このサービスには、元のサービスと同じサービスプロパティー (および追加のサービス) があります。
  2. サービスガードは、ターゲット OSGi サービスに関連する ACL を検索します (ACL は OSGi Config Admin サービスに保存されます)。
  3. ACL は、サービスでこの特定のメソッド呼び出しを実行できるロールのリストを返します。
  4. このコマンドの ACL が見つからない場合、サービスガードはデフォルトで etc/system.properties ファイルの karaf.secured.command.compulsory.roles プロパティーに指定されたロールのリストになります。
  5. サービスガードは、現在のセキュリティーサブジェクト (メソッド呼び出しを行ったユーザー) に対してロールのリストをチェックし、現在のユーザーに必要なロールがあるかどうかを調べます。
  6. 一致するロールが見つからない場合、メソッド呼び出しがブロックされ、SecurityException が発生します。
  7. または、一致するロールが見つかると、メソッド呼び出しは元の OSGi サービスに委譲されます。

デフォルトのセキュリティーロールの設定

対応する ACL ファイルがないコマンドの場合は、etc/system.properties ファイルに karaf.secured.command.compulsory.roles プロパティーを設定し (ロールのコンマ区切りリストとして指定)、デフォルトのセキュリティーロールのリストを指定します。

コマンドコンソール ACL ファイルの場所

コマンドコンソール ACL ファイルは、InstallDir/etc/auth ディレクトリーにあり、名前にプレフィックス org.apache.karaf.command.acl が付けられています。

コマンドスコープの ACL ファイル名へのマッピング

コマンドコンソールの ACL ファイル名は以下の命名規則に従います。

etc/auth/org.apache.karaf.command.acl.CommandScope.cfg

CommandScope は、Karaf コンソールコマンドの特定グループのプレフィックスに対応します。たとえば、feature:install および features:uninstall コマンドは、対応する ACL ファイル org.apache.karaf.command.acl.features.cfg を持つ feature コマンドスコープに属します。

ACL ファイルフォーマット

コマンドコンソール ACL ファイルの各行は、次の形式のエントリーです。

Pattern = Role1[,Role2][,Role3]...

Pattern は、現在のコマンドスコープから Karaf コンソールコマンドと一致するパターンで、等号記号の右側は、その呼び出しを行うユーザー権限を付与するロールのカンマ区切りリストです。最も単純なケースでは、Pattern は単にスコープ指定されていないコマンド名です。たとえば、org.apache.karaf.command.acl.feature.cfg ACL ファイルには、feature コマンドの以下のルールが含まれます。

list = admin, manager, viewer
repo-list = admin, manager, viewer
info = admin, manager, viewer
version-list = admin, manager, viewer
repo-refresh = admin, manager
repo-add = admin, manager
repo-remove = admin, manager
install = admin
uninstall = admin
重要

特定のコマンド名と一致するものが見つからない場合、このコマンドにロールは必要ないとみなされ、どのユーザーでも呼び出すことができます。

特定の引数や正規表現に一致する引数で呼び出されたコマンドと一致するパターンを定義することもできます。たとえば、org.apache.karaf.command.acl.bundle.cfg ACL ファイルはこの機能を利用して、通常のユーザーが -f (force) フラグで bundle:start コマンドと bundle:stop コマンドを呼び出さないようにします (システムバンドルを管理するために指定する必要があります)。この制限は、ACL ファイルで以下のようにコード化されます。

start[/.*[-][f].*/] = admin
start = admin, manager
stop[/.*[-][f].*/] = admin
stop = admin, manager

この場合、manager ロールには、通常 bundle:start および bundle:stop コマンドを呼び出す権限がありますが、admin ロールのみが force オプション -f でこれらのコマンドを呼び出す権限を持ちます。

ACL ファイル形式の完全な詳細は、etc/auth/org.apache.karaf.command.acl.bundle.cfg ファイルのコメントを参照してください。

起動時の動的な設定

コマンドコンソールの ACL 設定は完全に動的なので、システムの実行中に ACL 設定を変更でき、すでにログインしているユーザーであっても、数秒以内に変更が反映されます。

2.2.4. OSGi サービスの ACL の定義

OSGi サービス (システムレベルまたはアプリケーションレベルかどうか) にカスタム ACL を定義できます。デフォルトでは、OSGi サービスではアクセス制御が有効にされていません (コマンドコンソール ACL ファイルで事前設定された、Karaf コンソールコマンドを公開する OSGi サービスを除く)。本セクションでは、OSGi サービスのカスタム ACL を定義する方法と、特定のロールを使用してそのサービスでメソッドを呼び出す方法について説明します。

ACL ファイルフォーマット

OSGi サービス ACL ファイルには、以下のような、この ACL が適用される OSGi サービスを識別する特別なエントリーが 1 つあります。

service.guard = (objectClass=InterfaceName)

service.guard の値は、一致する OSGi サービスを選択するために OSGi サービスプロパティーのレジストリーに適用される LDAP 検索フィルターです。最も単純なフィルタータイプ (objectClass=InterfaceName) は、指定された Java インターフェース名 InterfaceName で OSGi サービスを選択します。

ACL ファイルの残りのエントリーは以下の形式になります。

Pattern = Role1[,Role2][,Role3]...

Pattern は、サービスメソッドと一致するパターンで、等号記号の右側は、その呼び出しを行う権限をユーザーに付与するロールのカンマ区切りリストです。これらのエントリーの構文は基本的に JMX ACL ファイルのエントリーと同じです。「ACL ファイルフォーマット」 を参照してください。

カスタム OSGi サービス の ACL を定義する方法

カスタム OSGi サービスの ACL を定義するには、以下の手順を実行します。

  1. Java インターフェースを使用して OSGi サービスを定義するのが通例です (通常の Java クラスを使用することもできますが、これは推奨されません)。たとえば、OSGi サービスとして公開する予定の Java インターフェース MyService について考えてみましょう。

    package org.example;
    
    public interface MyService {
      void doit(String s);
    }
  2. Java インターフェースを OSGi サービスとして公開するには、通常 service 要素を OSGi Blueprint XML ファイルに追加します (Blueprint XML ファイルは通常、Maven プロジェクトの src/main/resources/OSGI-INF/blueprint ディレクトリーに保存されます)。たとえば、MyServiceImplMyService インターフェースを実装するクラスであると仮定すると、以下のように MyService OSGi サービスを公開できます。

    <?xml version="1.0" encoding="UTF-8"?>
    <blueprint xmlns="http://www.osgi.org/xmlns/blueprint/v1.0.0"
                xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
                default-activation="lazy">
    
      <bean id="myserviceimpl" class="org.example.MyServiceImpl"/>
    
      <service id="myservice" ref="myserviceimpl" interface="org.example.MyService"/>
    
    </blueprint>
  3. OSGi サービスに ACL を定義するには、org.apache.karaf.service.acl プレフィックスが付いた OSGi Config Admin PID を作成する必要があります。

    たとえば、Karaf コンテナーの場合 (OSGi Config Admin PID は etc/auth/ ディレクトリー下に .cfg ファイルとして格納される)、MyService OSGi サービスに以下の ACL ファイルを作成できます。

    etc/auth/org.apache.karaf.service.acl.myservice.cfg
    注記

    必要なプレフィックス org.apache.karaf.service.acl で始まる限り、このファイルの命名方法は重要ではありません。この ACL ファイルに対応する OSGi サービスは、実際には、このファイルのプロパティー設定で指定されます (次のステップを参照)。

  4. ACL ファイルの内容を以下のような形式で指定します。

    service.guard = (objectClass=InterfaceName)
    Pattern = Role1[,Role2][,Role3]...

    service.guard 設定は OSGi サービスの InterfaceName を指定します (LDAP 検索フィルターの構文を使用)。これは OSGi サービスプロパティーに適用されます。ACL ファイルの他のエントリーは、一致するメソッドを指定されたロールに関連付ける Pattern メソッドで構成されます。たとえば、org.apache.karaf.service.acl.myservice.cfg ファイルで以下の設定を使用して、MyService OSGi サービスの簡単な ACL を定義できます。

    service.guard = (objectClass=org.example.MyService)
    doit = admin, manager, viewer
  5. 最後に、この OSGi サービスの ACL を有効にするには、etc/system.properties ファイルの karaf.secured.services プロパティーを編集する必要があります。karaf.secured.services プロパティーの値は LDAP 検索フィルターの構文を持ちます (OSGi サービスプロパティーに適用される)。一般的に、OSGi サービス ServiceInterface の ACL を有効にするには、以下のようにこのプロパティーを変更する必要があります。

    karaf.secured.services=(|(objectClass=ServiceInterface)(...ExistingPropValue...))

    たとえば、MyService OSGi サービスを有効にするには、以下を行います。

    karaf.secured.services=(|(objectClass=org.example.MyService)(&(osgi.command.scope=*)(osgi.command.function=*)))

    karaf.secured.services プロパティーの初期値には、コマンドコンソール ACL を有効にする設定があります。これらのエントリーを削除または破損すると、コマンドコンソール ACL が動作しなくなる可能性があります。

RBAC でセキュア化された OSGi サービスを呼び出す方法

カスタム OSGi サービス (OSGi サービスのクライアントの実装) でメソッドを呼び出す Java コードを記述する場合は、Java セキュリティー API を使用してサービスを呼び出すために使用するロールを指定する必要があります。たとえば、manager ロールを使用して MyService OSGi サービスを呼び出すには、以下のようなコードを使用します。

// Java
import javax.security.auth.Subject;
import org.apache.karaf.jaas.boot.principal.RolePrincipal;
// ...
Subject s = new Subject();
s.getPrincipals().add(new RolePrincipal("Deployer"));
Subject.doAs(s, new PrivilegedAction() {
  public Object run() {
    svc.doit("foo"); // invoke the service
  }
}
注記

この例では、Karaf ロールタイプ org.apache.karaf.jaas.boot.principal.RolePrincipal を使用します。必要な場合は、代わりに独自のカスタムロールクラスを使用することもできますが、その場合は OSGi サービスの ACL ファイルで構文 className:roleName を使用してロールを指定する必要があります。

OSGi サービスで必要なロールの検出方法

ACL で保護された OSGi サービスに対してコードを記述する場合、サービスを呼び出すために許可されているロールを確認すると便利な場合があります。このため、プロキシーサービスは、追加の OSGi プロパティー org.apache.karaf.service.guard.roles をエクスポートします。このプロパティーの値は java.util.Collection オブジェクトで、そのサービスでメソッドを呼び出す可能性があるすべてのロールのリストが含まれます。

2.3. 暗号化されたプロパティープレースホルダーの使用方法

Karaf コンテナーを保護するときに、設定ファイルでプレーンテキストのパスワードを使用しないでください。プレーンテキストのパスワードを使用しないようにする方法の 1 つは、可能な限り暗号化プロパティープレースホルダーを使用することです。詳細は以下のトピックを参照してください。

2.3.1. 値を暗号化するマスターパスワードについて

Jasypt を使用して値を暗号化するには、マスターパスワードが必要です。マスターパスワードを選択するのは、ユーザーまたは管理者です。Jasypt は、マスターパスワードを設定する複数の方法を提供します。

1 つの方法として、Blueprint 設定にマスターパスワードをプレーンテキストで指定します。例を以下に示します。

<blueprint xmlns="http://www.osgi.org/xmlns/blueprint/v1.0.0"
   	xmlns:enc="http://karaf.apache.org/xmlns/jasypt/v1.0.0">

  <enc:property-placeholder>
    <enc:encryptor class="org.jasypt.encryption.pbe.StandardPBEStringEncryptor">
      <property name="config">
        <bean class="org.jasypt.encryption.pbe.config.EnvironmentStringPBEConfig">
          <property name="algorithm" value="PBEWithMD5AndDES" />
          <property name="password" value="myPassword" />
        </bean>
      </property>
    </enc:encryptor>
  </enc:property-placeholder>

</blueprint>

プレーンテキストのマスターパスワードを指定する代わりに、以下のいずれかを行うことができます。

  • 環境変数をマスターパスワードに設定します。Blueprint 設定ファイルで、この環境変数を passwordEnvName プロパティーの値として指定します。たとえば、MASTER_PW 環境変数をマスターパスワードに設定すると、Blueprint 設定ファイルにこのエントリーが作成されます。

    <property name="passwordEnvName" value="MASTER_PW">

  • Karaf システムプロパティーをマスターパスワードに設定します。Blueprint 設定ファイルで、このシステムプロパティーを passwordSys プロパティーの値として指定します。たとえば、karaf.password システムプロパティーをマスターパスワードに設定すると、Blueprint 設定ファイルにこのエントリーが作成されます。

    <property name="passwordSys" value="karaf.password">

2.3.2. 暗号化されたプロパティープレースホルダーの使用

Karaf コンテナを保護する場合は、Blueprint 設定ファイルで暗号化されたプロパティープレースホルダーを使用します。

前提条件

  • 値を暗号化するためマスターパスワードを知っている。

手順

  1. デフォルトの暗号化アルゴリズム PBEWithMD5AndDES を使用するか、使用する暗号化アルゴリズムを次のように選択します。

    1. jasypt:list-algorithms コマンドを実行して、現在の Java 環境でサポートされるアルゴリズムを検出します。

      karaf@root()> jasypt:list-algorithms

      引数やオプションはありません。この出力は、サポートされるダイジェストおよび Password Based Encryption (PBE) アルゴリズムの識別子のリストです。このリストには、Fuse 7.9 の一部である Bouncy Castle ライブラリーによって提供されるアルゴリズムが含まれています。このリストは長くなる可能性があります。この一部は以下のようになります。

      karaf@root()> jasypt:list-algorithms
      DIGEST ALGORITHMS:
       - 1.0.10118.3.0.55
       - 1.2.804.2.1.1.1.1.2.2.1
          ...
       - 2.16.840.1.101.3.4.2.9
       - BLAKE2B-160
       - BLAKE2B-256
         ...
       - MD4
       - MD5
       - OID.1.0.10118.3.0.55
         ...
       - SHA3-512
       - SKEIN-1024-1024
       - SKEIN-1024-384
         ...
       - TIGER
       - WHIRLPOOL
      
      PBE ALGORITHMS:
       - PBEWITHHMACSHA1ANDAES_128
       - PBEWITHHMACSHA1ANDAES_256
          ...
       - PBEWITHSHA1ANDRC2_128
       - PBEWITHSHA1ANDRC2_40
          ...
       - PBEWITHSHAANDIDEA-CBC
       - PBEWITHSHAANDTWOFISH-CBC
    2. リストを確認し、使用する暗号化アルゴリズムの識別子を見つけます。セキュリティーの専門家に相談してアルゴリズムを選択することをお勧めします。
  2. 設定ファイルで使用するパスワードなど、機密性の高い設定値を暗号化するには、jasypt:encrypt コマンドを実行します。このコマンドの形式は次のとおりです。

    jasypt:encrypt [options] [input]

    オプションを指定せずにこのコマンドを呼び出して、暗号化する値を指定しないと、マスターパスワードと暗号化する値の入力を求められ、その他のオプションにはデフォルトが適用されます。以下に例を示します。

    karaf@root()> jasypt:encrypt
    Master password: ********
    Master password (repeat): ********
    Data to encrypt: *****
    Data to encrypt (repeat): *****
    Algorithm used: PBEWithMD5AndDES
    Encrypted data: oT8/LImAFQmOfXxuFGRDTAjD1l1+GxKL+TnHxFNwX4A=

    暗号化する値ごとに jasypt:encrypt コマンドを実行します。

    デフォルトの動作を変更するには、以下のオプションのいずれかを指定します。

    オプション説明

    -w または --password-property

    このオプションの後にマスターパスワードの値に設定された環境変数またはシステムプロパティーを指定します。Jasypt はこの値を暗号化アルゴリズムとともに使用して、暗号化キーを取得します。

    -w または -W オプションを指定しない場合は、コマンドの呼び出し後に、マスターパスワードの入力と確認が求められます。

    -w MASTER_PW

    -W または --password

    このオプションの後に選択したマスターパスワードのプレーンテキスト値を指定します。マスターパスワードのプレーンテキスト値は履歴に表示されます。

    Jasypt はこの値を暗号化アルゴリズムとともに使用して、暗号化キーを取得します。

    -w または -W オプションを指定しない場合は、コマンドの呼び出し後に、マスターパスワードの入力と確認が求められます。

    -W "M@s!erP#"

    -a または --algorithm

    このオプションの後に、jasypt:encrypt コマンドが最初の暗号鍵を取得するのに使用するアルゴリズムの識別子を指定します。デフォルトは PBEWithMD5AndDES です。

    jasypt-list-algorithms コマンドが出力するリストに含まれるすべてのアルゴリズムがサポートされます。コマンドラインでアルゴリズム名を指定すると、自動補完を使用できます。

    例: -a PBEWITHMD5ANDRC2

    -i または --iterations

    このオプションの後に、初期キーのハッシュを繰り返し作成する回数を示す整数を指定します。各繰り返しは前のハッシュ結果を取り、再度ハッシュします。結果は最終的な暗号化キーになります。デフォルトは 1000 です。

    例: -i 5000

    -h または --hex

    このオプションを指定して 16 進数の出力を取得します。デフォルトの出力は Base64 です。

    例: -h

    --help

    コマンド構文およびオプションに関する情報を表示します。

    jasypt:encrypt --help

  3. jasypt:encrypt コマンドを実行して、取得した暗号化された値が含まれるプロパティーファイルを作成します。ENC() 関数で暗号化された各値をラップします。

    たとえば、一部の LDAP クレデンシャルを etc/ldap.properties ファイルに保存する場合は、ファイルの内容は次のようになります。

    #ldap.properties
    ldap.password=ENC(VMJ5S566MEDhQ5r6jiIqTB+fao3NN4pKnQ9xU0wiDCg=)
    ldap.url=ldap://192.168.1.74:10389
  4. 暗号化されたプロパティープレースホルダーに必要な namespace を blueprint.xml ファイルに追加します。これらの namespace は Aries エクステンションおよび Apache Karaf Jasypt のためのものです。以下に例を示します。

    <blueprint xmlns="http://www.osgi.org/xmlns/blueprint/v1.0.0"
     	xmlns:ext="http://aries.apache.org/blueprint/xmlns/blueprint-ext/v1.0.0"
     	xmlns:enc="http://karaf.apache.org/xmlns/jasypt/v1.0.0">
    ...
    </blueprint>
  5. 使用した Jasypt 暗号化アルゴリズムの識別子と、プロパティーファイルの場所を設定します。これを行う方法の例は次のとおりです。

    • etc/ldap.properties ファイルからプロパティーを読み取るように ext:property-placeholder 要素を設定します。
    • enc:property-placeholder 要素を以下のように設定します。

      • PBEWithMD5AndDES 暗号化アルゴリズムを特定します。
      • Karaf bin/setenv ファイルで定義した環境変数 JASYPT_ENCRYPTION_PASSWORD からマスターパスワードを読み取ります。

        <blueprint xmlns="http://www.osgi.org/xmlns/blueprint/v1.0.0"
         	xmlns:ext="http://aries.apache.org/blueprint/xmlns/blueprint-ext/v1.0.0"
         	xmlns:enc="http://karaf.apache.org/xmlns/jasypt/v1.0.0">
        
          <ext:property-placeholder>
            <ext:location>file:etc/ldap.properties</ext:location>
          </ext:property-placeholder>
        
          <enc:property-placeholder>
            <enc:encryptor class="org.jasypt.encryption.pbe.StandardPBEStringEncryptor">
              <property name="config">
                <bean class="org.jasypt.encryption.pbe.config.EnvironmentStringPBEConfig">
                  <property name="algorithm" value="PBEWithMD5AndDES" />
                  <property name="passwordEnvName" value="JASYPT_ENCRYPTION_PASSWORD" />
                </bean>
              </property>
            </enc:encryptor>
          </enc:property-placeholder>
        …
        </blueprint>

初期化ベクタープロパティーの設定

以下のアルゴリズムでは、ivGenerator という名前の初期化ベクタープロパティーを Blueprint 設定に追加する必要があります。

PBEWITHHMACSHA1ANDAES_128
PBEWITHHMACSHA1ANDAES_256
PBEWITHHMACSHA224ANDAES_128
PBEWITHHMACSHA224ANDAES_256
PBEWITHHMACSHA256ANDAES_128
PBEWITHHMACSHA256ANDAES_256
PBEWITHHMACSHA384ANDAES_128
PBEWITHHMACSHA384ANDAES_256
PBEWITHHMACSHA512ANDAES_128
PBEWITHHMACSHA512ANDAES_256

以下の例は、必要に応じて、Blueprint 設定に ivGenerator プロパティーを追加する方法を示しています。

<enc:property-placeholder>
  <enc:encryptor class="org.jasypt.encryption.pbe.StandardPBEStringEncryptor">
    <property name="config">
      <bean class="org.jasypt.encryption.pbe.config.EnvironmentStringPBEConfig">
        <property name="algorithm" value="PBEWITHHMACSHA1ANDAES_128"/>
        <property name="passwordEnvName" value="JASYPT_ENCRYPTION_PASSWORD"/>
        <property name="ivGenerator">
          <bean class="org.jasypt.iv.RandomIvGenerator" />
        </property>
      </bean>
    </property>
  </enc:encryptor>
</enc:property-placeholder>

暗号化されたプロパティープレースホルダーを使用する LDAP JAAS レルム設定

以下の例は、Jasypt 暗号化プロパティープレースホルダーを使用する LDAP JAAS レルム設定を表示し、前述の例の blueprint.xml ファイルに追加します。

注記

このトピックで説明されているプロセスを使用してプロパティーを暗号化する場合は、@PropertyInject アノテーションを使用してプロパティーを復号化できません。代わりに、この Blueprint の例にあるように、XML を使用してプロパティーを Java オブジェクトにインジェクトします。

この例では、コンテナーの初期化中に ${ldap.password} プレースホルダーは、etc/ldap.properties ファイルからの ldap.password プロパティーの復号化された値に置き換えられます。

<blueprint xmlns="http://www.osgi.org/xmlns/blueprint/v1.0.0"
 	xmlns:ext="http://aries.apache.org/blueprint/xmlns/blueprint-ext/v1.0.0"
 	xmlns:enc="http://karaf.apache.org/xmlns/jasypt/v1.0.0">

  <ext:property-placeholder>
    <location>file:etc/ldap.properties</location>
  </ext:property-placeholder>

  <enc:property-placeholder>
    <enc:encryptor class="org.jasypt.encryption.pbe.StandardPBEStringEncryptor">
      <property name="config">
        <bean class="org.jasypt.encryption.pbe.config.EnvironmentStringPBEConfig">
          <property name="algorithm" value="PBEWithMD5AndDES" />
          <property name="passwordEnvName" value="JASYPT_ENCRYPTION_PASSWORD" />
        </bean>
      </property>
    </enc:encryptor>
  </enc:property-placeholder>

  <jaas:config name="karaf" rank="200">
    <jaas:module className="org.apache.karaf.jaas.modules.ldap.LDAPLoginModule" flags="required">
      initialContextFactory=com.sun.jndi.ldap.LdapCtxFactory
      debug=true
        connectionURL=${ldap.url}
        connectionUsername=cn=mqbroker,ou=Services,ou=system,dc=jbossfuse,dc=com
        connectionPassword=${ldap.password}
        connectionProtocol=
        authentication=simple
        userRoleName=cn
        userBase = ou=User,ou=ActiveMQ,ou=system,dc=jbossfuse,dc=com
        userSearchMatching=(uid={0})
        userSearchSubtree=true
        roleBase = ou=Group,ou=ActiveMQ,ou=system,dc=jbossfuse,dc=com
        roleName=cn
        roleSearchMatching= (member:=uid={1})
        roleSearchSubtree=true
    </jaas:module>
  </jaas:config>

</blueprint>

環境変数またはシステムプロパティーを指定する例

値を暗号化する際にプレーンテキストのマスターパスワードを指定するのではなく、マスターパスワードに設定される環境変数またはシステムプロパティーを指定できます。たとえば、bin/setenv ファイルに以下が含まれているとします。

export MASTER_PASSWORD=passw0rd

次のコマンドで値を暗号化できます。

karaf@root()> jasypt:encrypt -w MASTER_PASSWORD "$en$!t!ve"
Algorithm used: PBEWithMD5AndDES
Encrypted data: /4DZCwqXD7cQ++TKQjt9QzmmcWv7TwmylCPkHumv2LQ=

etc/system.properties ファイルに以下の内容が含まれている場合:

master.password=passw0rd

次のコマンドで値を暗号化できます。

karaf@root()> jasypt:encrypt -w master.password "$en$!t!ve"
Algorithm used: PBEWithMD5AndDES
Encrypted data: 03+8UTJJtEXxHaJkVCmzhqLMUYtT8TBG2RMvOBQlfmQ=

2.3.3. jasypt:digest コマンドの呼び出し

Jasypt digest は、MD5 などの暗号化ハッシュ機能を値に適用した結果です。ダイジェストの生成は、一方向暗号化の一種です。ダイジェストを生成し、ダイジェストから元の値を再構築することはできません。特に機密性の高い値については、値を暗号化するのではなく、ダイジェストを生成する場合があります。これにより、ダイジェストをプロパティープレースホルダーとして指定できます。

コマンドを呼び出してダイジェストを生成するための形式は次のとおりです。

jasypt:digest [options] [input]

オプションを指定せず、ダイジェストを作成する入力を指定しない場合、コマンドは暗号化する値の指定を要求し、オプションのデフォルト値を適用します。以下に例を示します。

karaf@root()> jasypt:digest
Input data to digest: ********
Input data to digest (repeat): ********
Algorithm used: MD5
Digest value: 8D4C0B3D5EE133BCFD7585A90F15C586741F814BC527EAE2A386B9AA6609B926AD9B3C418937251373E08F18729AD2C93815A7F14D878AA0EF3268AA04729A614ECAE95029A112E9AD56FEDD3FD7E28B73291C932B6F4C894737FBDE21AB382

以下の例は、コマンドラインでの input 引数の指定を示しています。

karaf@root()> jasypt:digest ImportantPassword

このコマンドはデフォルトのオプションを適用し、ImportantPassword の一方向暗号化を提供するダイジェストを生成します。コマンドの出力は以下のようになります。

karaf@root()> jasypt:digest ImportantPassword
Algorithm used: MD5
Digest value: 0bL90nno/nHiTEdzx3dKa61LBDcWQQZMpjaONtY3b1fJBuDWbWTTtZ6tE5eOOPKh7orLTXS7XRt2blA2DrfnjWIlIETjge9n

一方向暗号化が必要な各値に jasypt:digest コマンドを実行します。

デフォルトの動作を変更するには、以下のオプションのいずれかを指定します。

オプション説明

-a または --algorithm

このオプションの後に、jasypt:digest コマンドでダイジェストを生成するために使用するダイジェストアルゴリズムの識別子を指定します。デフォルトは MD5 です。

jasypt-list-algorithms コマンドが出力するリストに含まれるすべてのダイジェストアルゴリズムがサポートされます。コマンドラインでアルゴリズム名を指定すると、自動補完を使用できます。

例: -a SHA-12

-i または --iterations

このオプションの後に、初期ダイジェストのハッシュを繰り返し作成する回数を示す整数を指定します。各繰り返しは前のハッシュ結果を取り、再度ハッシュします。結果は最終的なダイジェストです。デフォルトは 1000 です。

例: -i 5000

-s または --salt-size

このオプションの後に、jasypt:digest ダイジェストの作成に適用される salt のバイト数を示す整数を指定します。これは、機密性の高い値のダイジェストを生成し、複数の場所にダイジェストを指定する必要がある場合に便利です。たとえば、同じ入力値で異なる salt サイズを使用して jasypt:digest を呼び出すことができます。入力が同じであっても、コマンドごとに異なるダイジェストが生成されます。デフォルトは 8 です。

例: -s 12

-h または --hex

このオプションを指定して 16 進数の出力を取得します。デフォルトの出力は Base64 です。

例: -h

--help

コマンド構文およびオプションに関する情報を表示します。

jasypt:digest --help

ダイジェストの取得後、「Using encrypted property placeholders」に記載されているのと同じ方法で使用できます。

デフォルト以外の値を使用する場合は、計算に時間がかかります。以下に例を示します。

karaf@root()> jasypt:digest --iterations 1000000 --salt-size 32 -a SHA-512 --hex passw0rd
Algorithm used: SHA-512
Digest value: 4007A85C4932A399D8376B4F2B3221E34F0AF349BB152BEAC80F03BEB2B368DA7900F0990C186DB36D61741FA147B96DC9F73481991506FAA3662EA1693642CDAB89EB7E6B1DC21E1443D06D70A5842EB2851D37E262D5FC77A1D0909B3B2783

2.3.4. jasypt:decrypt コマンドの呼び出し

暗号化されるプレースホルダーの元の値を検証するには、プレースホルダーで jasypt:decrypt コマンドを呼び出します。jasypt:encrypt コマンドを呼び出してプレースホルダーを生成しておく必要があります。以下を知っている必要があります。

  • マスターパスワードまたは環境変数、またはマスターパスワードに設定されるシステムプロパティー。
  • jasypt:encryptコマンドが値を暗号化するために使用したアルゴリズム。
  • jasypt:encryptコマンドが元の値を暗号化するために使用した反復回数。

jasypt:decryptコマンドを呼び出すための形式は次のとおりです。

jasypt:decrypt [options] [input]

オプションを指定せず、復号化する暗号化された入力を指定しない場合、コマンドはマスターパスワードと復号化する値の入力を求め、その他のオプションにデフォルト値を適用します。この復号化の例を正常に実行するには、jasypt:encrypt コマンドがデフォルトを使用して値を暗号化する必要があります。以下に例を示します。

karaf@root()> jasypt:decrypt
Master password: ********
Data to decrypt: ********************************************
Algorithm used: PBEWithMD5AndDES
Decrypted data: $en$!t!ve

このコマンドは、指定するマスターパスワードとデフォルトのアルゴリズム (PBEWithMD5AndDES) を使用して復号化キーを作成します。次に、このコマンドはこの復号化キーを使用して、プロンプトで入力する値を復号化します。

デフォルトの動作を変更するには、以下のオプションのいずれかを指定します。

オプション説明

-w または --password-property

このオプションの後にマスターパスワードの値に設定された環境変数またはシステムプロパティーを指定します。Jasypt はこの値を復号化アルゴリズムとともに使用して、最初の復号化キーを取得します。

-w または -W オプションを指定しない場合は、コマンドの呼び出し後に、マスターパスワードの入力と確認が求められます。

-w MASTER_PW

-W または --password

このオプションの後に選択したマスターパスワードのプレーンテキスト値を指定します。マスターパスワードのプレーンテキスト値は履歴に表示されます。

Jasypt はこの値を復号化アルゴリズムとともに使用して、最初の復号化キーを取得します。

-w または -W オプションを指定しない場合は、コマンドの呼び出し後に、マスターパスワードの入力と確認が求められます。

-W "M@s!erP#"

-a または --algorithm

このオプションの後に、jasypt:decrypt コマンドが最初の復号鍵を取得するのに使用するアルゴリズムの識別子を指定します。デフォルトは PBEWithMD5AndDES です。

jasypt:decrypt コマンドは、指定したプレースホルダー入力を生成するために jasypt:encrypt コマンドが使用したものと同じアルゴリズムを使用する必要があります。

jasypt-list-algorithms コマンドが出力するリストに含まれるすべてのアルゴリズムがサポートされます。コマンドラインでアルゴリズム名を指定すると、自動補完を使用できます。

例: -a PBEWITHMD5ANDRC2

-i または --iterations

このオプションの後に、初期キーのハッシュを繰り返し作成する回数を示す整数を指定します。各繰り返しは前のハッシュ結果を取り、再度ハッシュします。結果は最終的な復号化キーになります。デフォルトは 1000 です。

jasypt:decrypt コマンドは、指定したプレースホルダー入力を生成するために jasypt:encrypt コマンドが使用したものと同じ反復回数を使用する必要があります。

例: -i 5000

-h または --hex

このオプションを指定して 16 進数の出力を取得します。デフォルトの出力は Base64 です。

例: -h

-E または --use-empty-iv-generator

以前のバージョンの Jasypt で暗号化したパスワードを復号化するために、固定された IV ジェネレーターを使用します。

例: -E

--help

コマンド構文およびオプションに関する情報を表示します。

jasypt:decrypt --help

環境変数またはシステムプロパティーを指定する例

値を復号化する際にプレーンテキストのマスターパスワードを指定するのではなく、マスターパスワードに設定される環境変数またはシステムプロパティーを指定できます。たとえば、bin/setenv ファイルに以下が含まれているとします。

export MASTER_PASSWORD=passw0rd

次のコマンドで値を復号化できます。

karaf@root()> jasypt:decrypt -a -w MASTER_PASSWORD
Data to decrypt: ********************************************
Algorithm used: PBEWithMD5AndDES
Decrypted data: $en$!t!ve

etc/system.properties ファイルに以下の内容が含まれている場合:

master.password=passw0rd

次のコマンドで値を復号化できます。

karaf@root()> jasypt:decrypt -w master.password
Data to decrypt: ********************************************
Algorithm used: PBEWithMD5AndDES
Decrypted data: $en$!t!ve

2.4. リモート JMX SSL の有効化

概要

Red Hat JBoss Fuse は、MBean を使用して Karaf コンテナーのリモート監視および管理を可能にする JMX ポートを提供します。ただし、デフォルトでは、JMX 接続上で送信するクレデンシャルは暗号化されず、スヌーピングに対して脆弱です。JMX 接続を暗号化し、パスワードスヌーピングから保護するには、JMX over SSL を設定して JMX 通信をセキュアにする必要があります。

JMX over SSL を設定するには、以下の手順を実行します。

JMX over SSL の設定後、接続をテストする必要があります。

警告

SSL/TLS セキュリティーを有効にする場合、Poodle の脆弱性 (CVE-2014-3566) から保護するために、SSLv3 プロトコルを明示的に無効にする必要があります。詳細は、「Disabling SSLv3 in JBoss Fuse 6.x and JBoss A-MQ 6.x」を参照してください。

注記

Red Hat JBoss Fuse の稼働中に JMX over SSL を設定する場合は、再起動する必要があります。

前提条件

まだ行っていない場合は、以下を行う必要があります。

  • JAVA_HOME 環境変数の設定
  • admin ロールを使用した Karaf ユーザーの設定

    InstallDir/etc/users.properties ファイルを編集し、次のエントリーを 1 行で追加します。

    admin=YourPassword,admin

    これにより、ユーザー名 admin、パスワード YourPassword、および admin ロールを持つ新規ユーザーが作成されます。

jbossweb.keystore ファイルの作成

コマンドプロンプトを開き、現在の場所が Karaf インストールの etc/ ディレクトリーであることを確認します。

cd etc

コマンドラインで、アプリケーションに適した -dname 値 (識別名) を使用して、以下のコマンドを入力します。

$JAVA_HOME/bin/keytool -genkey -v -alias jbossalias -keyalg RSA -keysize 1024 -keystore jbossweb.keystore -validity 3650 -keypass JbossPassword -storepass JbossPassword -dname "CN=127.0.0.1, OU=RedHat Software Unit, O=RedHat, L=Boston, S=Mass, C=USA"
重要

コマンド全体を 1 つのコマンドラインで入力します。

このコマンドは、以下のような出力を返します。

Generating 1,024 bit RSA key pair and self-signed certificate (SHA256withRSA) with a validity of 3,650 days
	for: CN=127.0.0.1, OU=RedHat Software Unit, O=RedHat, L=Boston, ST=Mass, C=USA
New certificate (self-signed):
[
[
  Version: V3
  Subject: CN=127.0.0.1, OU=RedHat Software Unit, O=RedHat, L=Boston, ST=Mass, C=USA
  Signature Algorithm: SHA256withRSA, OID = 1.2.840.113549.1.1.11

  Key:  Sun RSA public key, 1024 bits
  modulus: 1123086025790567043604962990501918169461098372864273201795342440080393808
     1594100776075008647459910991413806372800722947670166407814901754459100720279046
     3944621813738177324031064260382659483193826177448762030437669318391072619867218
     036972335210839062722456085328301058362052369248473659880488338711351959835357
  public exponent: 65537
  Validity: [From: Thu Jun 05 12:19:52 EDT 2014,
               To: Sun Jun 02 12:19:52 EDT 2024]
  Issuer: CN=127.0.0.1, OU=RedHat Software Unit, O=RedHat, L=Boston, ST=Mass, C=USA
  SerialNumber: [    4666e4e6]

Certificate Extensions: 1
[1]: ObjectId: 2.5.29.14 Criticality=false
SubjectKeyIdentifier [
KeyIdentifier [
0000: AC 44 A5 F2 E6 2F B2 5A   5F 88 FE 69 60 B4 27 7D  .D.../.Z_..i`.'.
0010: B9 81 23 9C                                        ..#.
]
]

]
  Algorithm: [SHA256withRSA]
  Signature:
0000: 01 1D 95 C0 F2 03 B0 FD   CF 3A 1A 14 F5 2E 04 E5  .........:......
0010: DD 18 DD 0E 24 60 00 54   35 AE FE 36 7B 38 69 4C  ....$`.T5..6.8iL
0020: 1E 85 0A AF AE 24 1B 40   62 C9 F4 E5 A9 02 CD D3  .....$.@b.......
0030: 91 57 60 F6 EF D6 A4 84   56 BA 5D 21 11 F7 EA 09  .W`.....V.]!....
0040: 73 D5 6B 48 4A A9 09 93   8C 05 58 91 6C D0 53 81  s.kHJ.....X.l.S.
0050: 39 D8 29 59 73 C4 61 BE   99 13 12 89 00 1C F8 38  9.)Ys.a........8
0060: E2 BF D5 3C 87 F6 3F FA   E1 75 69 DF 37 8E 37 B5  ...<..?..ui.7.7.
0070: B7 8D 10 CC 9E 70 E8 6D   C2 1A 90 FF 3C 91 84 50  .....p.m....<..P

]
[Storing jbossweb.keystore]

InstallDir/etc にファイル jbossweb.keystore が含まれるかどうかを確認します。

keystore.xml ファイルの作成およびデプロイ

  1. 任意の XML エディターを使用して、keystore.xml ファイルを作成し、<installDir>/jboss-fuse-7.8.0.fuse-780038-redhat-00001/etc ディレクトリーに保存します。
  2. このテキストをファイルに追加します。

    <blueprint xmlns="http://www.osgi.org/xmlns/blueprint/v1.0.0"
    xmlns:jaas="http://karaf.apache.org/xmlns/jaas/v1.0.0">
    <jaas:keystore name="sample_keystore"
    rank="1"
    path="file:etc/jbossweb.keystore"
    keystorePassword="JbossPassword"
    keyPasswords="jbossalias=JbossPassword" />
    </blueprint>
  3. keystore.xml ファイルを InstallDir/deploy ディレクトリー (ホットデプロイディレクトリー) にコピーして、 Karaf コンテナーにデプロイします。

    注記

    その後、keystore.xml ファイルをアンデプロイする必要がある場合は、Karaf コンテナーの実行中deploy/ ディレクトリーから keystore.xml ファイルを削除して実行できます。

必要なプロパティーの org.apache.karaf.management.cfg への追加

InstallDir/etc/org.apache.karaf.management.cfg ファイルを編集し、ファイルの末尾にこれらのプロパティーを追加します。

secured = true
secureProtocol = TLSv1
keyAlias = jbossalias
keyStore = sample_keystore
trustStore = sample_keystore
重要

Poodle 脆弱性 (CVE-2014-3566) から保護するには、secureProtocolTLSv1 に設定する必要があります。

注記

必要に応じて、enabledCipherSuites プロパティーを設定して、JMX TLS 接続に使用する特定の暗号スイートをリストできます。このプロパティーを設定すると、デフォルトの暗号スイートが上書きされます。

Karaf コンテナーの再起動

新しい JMX SSL/TLS 設定を有効にするには、Karaf コンテナーを再起動する必要があります。

セキュアな JMX 接続のテスト

  1. コマンドプロンプトを開き、現在の場所が Fuse インストールの etc/ ディレクトリーであることを確認します。

    cd <installDir>/jboss-fuse-7.8.0.fuse-780038-redhat-00001/etc
  2. ターミナルを開き、以下のコマンドを実行して JConsole を起動します。

    jconsole -J-Djavax.net.debug=ssl -J-Djavax.net.ssl.trustStore=jbossweb.keystore -J-Djavax.net.ssl.trustStoreType=JKS -J-Djavax.net.ssl.trustStorePassword=JbossPassword

    -J-Djavax.net.ssl.trustStore オプションは、jbossweb.keystore ファイルの場所を指定します (この場所を正しく指定しないと、SSL/TLS ハンドシェイクに失敗します)。-J-Djavax.net.debug=ssl 設定により SSL/TLS ハンドシェイクメッセージのロギングが有効になるため、SSL/TLS が正常に有効になっていることを確認できます。

    重要

    同じコマンドラインでコマンド全体を入力します。

  3. JConsole が開いたら、New Connection ウィザードで Remote Process オプションを選択します。
  4. Remote Process オプションで、service:jmx:<protocol>:<sap> 接続 URL に以下の値を入力します。

    service:jmx:rmi://localhost:44444/jndi/rmi://localhost:1099/karaf-root

    さらに、Username および Password フィールドに、有効な JAAS クレデンシャルを入力します (etc/users.properties ファイルで設定されているように)。

    Username: admin
    Password: YourPassword

2.5. Elytron クレデンシャルストアの使用

Fuse には、JBoss EAP の一部である Elytron クレデンシャルストア機能が含まれています。クレデンシャルストアでは、機密性の高いテキスト文字列をストレージファイルで暗号化して安全に保護できます。各コンテナーはクレデンシャルストアを 1 つだけ持つことができます。

安全な設定では、一般的な問題はパスワードの保存方法です。たとえば、さまざまなアプリケーションからデータベースにアクセスするパスワードについて考えてみましょう。多くの認証方法では、サーバーがクレデンシャルをデータベースサーバーに送信する前に、クリアテキストのパスワードが必要です。テキスト設定ファイルのクリアテキストパスワードのストレージは、一般的には適していません。

Elytron クレデンシャルストアはこの問題を解決します。パスワードおよびその他の機密値をクレデンシャルストアに安全に保存できます。これは、PKCS#12 仕様に準拠する暗号化されたファイルです。クレデンシャルストアは、暗号化されていない値を格納しません。クレデンシャルストアは、PBE (Password Based Encryption) を使用して、パスワードなどの機密性の高い値とストア自体の両方を暗号化します。

詳細は以下を参照してください。

2.5.1. クレデンシャルストアの使用

Fuse を実行している Apache Karaf コンテナーで、クレデンシャルストアを使用するには、クレデンシャルストアを作成および設定し、値を追加します。Fuse は実行を継続し、クレデンシャルストアを使用できます。

前提条件

  • クレデンシャルストアの作成時に、以下のデフォルトを使用します。

    • PKCS#12 クレデンシャルストアを作成します。
    • masked-SHA1-DES-EDE アルゴリズムを適用してクレデンシャルストアを暗号化します。
    • アルゴリズムを 200000 回繰り返します。
    • ${karaf.etc}/credential.store.p12 でクレデンシャルストアを見つけます。
  • クレデンシャルストア設定を ${karaf.etc}/system.properties に保存します。

この動作を変更する必要がある場合は、credential-store:create コマンドの呼び出しに関する情報を参照してください。

手順

  1. クレデンシャルストアパスワードを選択します。

    後で値をクレデンシャルストアに追加する場合や、値を復号化する場合、クレデンシャルストアコマンドはクレデンシャルストアパスワードを使用して値を暗号化および復号化します。

  2. credential-store:create コマンドを実行します。これにより、選択したクレデンシャルストアのパスワードを入力するよう要求されます。

    karaf@root()> credential-store:create --persist
    Credential store password: *****
    Credential store password (repeat): *****
    
    Credential store configuration was persisted in ${karaf.etc}/system.properties and is effective.
    
    Credential store was written to /data/servers/fuse-karaf-7.4.0.fuse-740060/etc/credential.store.p12
    
    By default, only system properties are encrypted.
    Encryption of configuration admin properties can be enabled by setting
    felix.cm.pm=elytron in etc/config.properties.

    このコマンドは、etc/system.properties に以下のような設定を書き込みます。

    credential.store.location = /data/servers/fuse-karaf-7.4.0.fuse-740060/etc/credential.store.p12
    credential.store.protection.algorithm = masked-SHA1-DES-EDE
    credential.store.protection.params = MDkEKFJId25PaXlVQldKUWw5R2tLclhZQndpTGhhVXJsWG5lNVJMbTFCZEMCAwMNQAQI0Whepb7H1BA=
    credential.store.protection = m+1BcfRyCnI=
  3. 以下のように credential-store:store コマンドを実行し、暗号化された値をクレデンシャルストアに追加します。

    credential-store:store alias

    alias を一意の鍵値に置き換えます。後で、クレデンシャルストアに追加する暗号化された値を取得するために、ツールでこのエイリアスを使用します。たとえば、コードで db.password システムプロパティーを使用し、etc/system.properties ファイルに db.password プロパティーをデータベースの実際のパスワードに設定するエントリーがあるとします。システムプロパティー db.password をエイリアスとして指定することが推奨されます。

    このコマンドを実行すると、クレデンシャルストアに追加する機密性の高い値の入力と確認が求められます。プロンプトが表示されたら、db.password エイリアスの例を続行し、データベースの実際のパスワードを入力します。

    karaf@root()> credential-store:store db.password
    Secret value to store: ******
    Secret value to store (repeat): ******
    Value stored in the credential store. To reference it use: CS:db.password
  4. etc/system.properties ファイルのエントリーを更新するか、新しいエントリーを追加します。更新または追加するエントリーは、credential-store:store コマンドで指定したエイリアスを、コマンドが出力する参照値に設定します。以下に例を示します。

    db.password = CS:db.password

    Fuse が設定されたクレデンシャルストアで稼働している場合、db.password システムプロパティーなどの各インスタンスを、クレデンシャルストアにある実際のシークレット値に動的に置き換えます。

  5. credential-store:store コマンドでは、指定したエイリアスが既に使用されているシステムプロパティーである場合は、次のステップをスキップします。シークレットに指定したエイリアスがコードで使用されていない場合、シークレットを必要とする各ファイルで、直前の手順でシステムプロパティーとして追加したエイリアスを指定します。たとえば、コードは db.password を参照します。
  6. クレデンシャルストアに追加する値ごとに、前述の 3 つの手順を繰り返します。

結果

クレデンシャルストアが使用できる状態になります。Fuse が起動するか、クレデンシャルストアバンドルが再起動すると、システムプロパティーが処理され、クレデンシャルストアエントリーを参照しているものを見つけます。Fuse は各システムプロパティーに対し、クレデンシャルストアから関連する値を取得し、システムプロパティーを実際のシークレット値に置き換えます。その後、実際のシークレット値は、そのシステムプロパティーのインスタンスが含まれるすべてのコンポーネント、バンドル、およびコードで利用できます。

2.5.2. システムプロパティーがクレデンシャルストア設定を保持する場合の動作

クレデンシャルストアが使用されており、システムプロパティーを使用してその設定パラメーターを保持することを仮定します。Fuse が起動するとすべてのシステムプロパティーが処理されます。Fuse は、CS: プレフィックスを持つ値に設定されたシステムプロパティーをクレデンシャルストアにある関連する値に置き換えます。Fuse は java.lang:type=Runtime JMX MBean をプロキシし、JMXgetSystemProperties() メソッドの呼び出しごとに復号化された値を非表示にします。

たとえば、1 つのエントリーを持つクレデンシャルストアについて考えてみましょう。

karaf@root()> credential-store:list --show-secrets
Alias       │ Reference      │ Secret value
────────────┼────────────────┼─────────────
db.password │ CS:db.password │ sec4et

このエントリーをクレデンシャルストアに追加した後に、etc/system.properties ファイルを編集し、次のエントリーを追加したとします。

db.password = CS:db.password

Fuse が org.jboss.fuse.modules.fuse-credential-store-core バンドルを起動または再起動すると、Fuse は db.password システムプロパティーへの参照をチェックします。各参照で、Fuse は CS:db.password エイリアスを使用してクレデンシャルストアから関連する値を取得します。これを確認するには、以下のコマンドを実行します。

karaf@root()> system:property db.password
sec4et

ただし、JMX を使用してこれを確認すると、クレデンシャルストアの値は非表示になります。

hidden value when checking by means of JMX

2.5.3. クレデンシャルストアシステムプロパティーおよび環境変数の説明

システムプロパティーまたは環境変数を使用して、クレデンシャルストアの設定パラメーターを保持できます。クレデンシャルストアの作成時に指定するオプションにより、以下が決定されます。

  • プロパティーまたは変数を独自に設定する必要があるかどうか。
  • プロパティーまたは変数が設定されている、または設定する必要がある正確な値。

プロパティー/変数を理解すると、クレデンシャルストアが機能する仕組みを理解するのに役立ちます。

credential-store:create コマンドを実行し、--persist オプションのみを指定すると、コマンドはシステムプロパティーをクレデンシャルストア設定パラメーターに設定します。クレデンシャルストアのシステムプロパティーを明示的に設定する必要はありません。

代わりにクレデンシャルストアの環境変数を使用するか、credential-store:create コマンドのデフォルト動作を変更する場合、クレデンシャルストアの作成時に指定できるオプションに関する詳細は、credential-store:create コマンドリファレンス を参照してください。

クレデンシャルストアを作成するコマンドを実行すると、指定するオプションによってクレデンシャルストアプロパティーまたは変数の設定が決定されます。プロパティーまたは変数を独自に設定する必要がある場合、credential-store:create コマンドの出力には、その手順が含まれます。つまり、クレデンシャルストアのシステムプロパティーまたは環境変数の設定をユーザーが決定することはできません。credential-store:create コマンドを実行すると常に設定が決定されます。

以下の表は、クレデンシャルストアのプロパティーおよび変数を示しています。特定のパラメーターでは、環境変数とシステムプロパティーの両方が設定されている場合、環境変数の設定が優先されます。

名前説明

環境変数: CREDENTIAL_STORE_PROTECION_ALGORITHM

システムプロパティー: credential.store.protection.algorithm

クレデンシャルストアが暗号化キーを取得するために使用する PBE (Password Based Encryption) アルゴリズム。

環境変数: CREDENTIAL_STORE_LOCATION

システムプロパティー: credential.store.location

クレデンシャルストアの場所。

環境変数: CREDENTIAL_STORE_PROTECTION_PARAMS

システムプロパティー: credential.store.protection.params

クレデンシャルストアが暗号化キーを取得するために使用するパラメーター。パラメーターには、反復回数、初期ベクトル、salt が含まれます。

環境変数: CREDENTIAL_STORE_PROTECTION

システムプロパティー: credential.store.protection

クレデンシャルストアからパスワードやその他のセキュアなデータをリカバリーするために、クレデンシャルストアコマンドが復号化する必要があるパスワード。credential-store:create コマンドを実行すると、このコマンドによりパスワードの指定が求められます。このパスワードの暗号化は、この環境変数またはシステムプロパティーの設定です。

2.5.4. credential-store:create コマンドリファレンス

クレデンシャルストアを作成および設定するには、以下の形式の credential-store:create コマンドを実行します。

credential-store:create [options]

オプションを指定しないと、このコマンドにより以下が行われます。

  • 選択したクレデンシャルストアパスワードの要求
  • PKCS#12 クレデンシャルストアの作成
  • masked-SHA1-DES-EDE アルゴリズムを使用したクレデンシャルストアの暗号化
  • アルゴリズムを 200000 回繰り返す
  • ${karaf.etc}/credential.store.p12 でのクレデンシャルストアの特定
  • クレデンシャルストア設定は保存しない

以下の表は、デフォルトの動作を変更するために指定できるオプションを示しています。

オプション説明

-w または --password-property

このオプションの後にマスターパスワードの値に設定された環境変数またはシステムプロパティーを指定します。クレデンシャルストアは、この値をアルゴリズムとともに使用して、暗号化または復号化キーを取得します。

-w または -W オプションを指定しない場合は、コマンドの呼び出し後に、マスターパスワードの入力と確認が求められます。

例: -w MASTER_PW

-W または --password

このオプションの後に選択したマスターパスワードのプレーンテキスト値を指定します。マスターパスワードのプレーンテキスト値は履歴に表示されます。

クレデンシャルストアは、この値をアルゴリズムとともに使用して、暗号化または復号化キーを取得します。

-w または -W オプションを指定しない場合は、コマンドの呼び出し後に、マスターパスワードの入力と確認が求められます。

例: -W "M@s!erP#"

-f または --force

クレデンシャルストアの作成を強制します。クレデンシャルストアが新しいクレデンシャルストアの目的の場所にある場合、このオプションを指定するとコマンドは既存のクレデンシャルストアを上書きします。既存のクレデンシャルストアの内容はすべて失われます。

デフォルトの動作では、目的の場所にクレデンシャルストアがすでにある場合、コマンドはクレデンシャルストアを作成しません。

-l または --location

新しいクレデンシャルストアの場所を指定します。デフォルトの場所である ${karaf.etc}/credential.store.p12 を使用することが推奨されます。

-ic または --iteration-count

このオプションの後に、使用されている暗号化アルゴリズムを繰り返し適用する回数を示す整数を指定します。繰り返しごとに前の結果を取り、再度アルゴリズムを適用します。結果は、最終的なマスクされたパスワードです。デフォルトは 200000 です。

-a または --algorithm

このオプションの後に、マスクされたパスワードを生成するために credential-store:create コマンドで使用されるアルゴリズムの識別子を指定します。デフォルトの masked-SHA1-DES-EDE を使用することが推奨されます。

-p または --persist

新しいクレデンシャルストアの設定を ${karaf.etc}/system.properties に保存します。このオプションを指定しないと、credential-store:create コマンドは次に行う手順が含まれる設定情報をコンソールに送信します。この表の後の例を参照してください。

このオプションを省略する理由は、クレデンシャルストアの設定パラメーターの値を確認するためです。または、etc/system.properties ファイルを使用せずにクレデンシャルストア設定パラメーターをアプリケーションに渡す予定であるため、このオプションを省略することもできます。

--help

コマンド構文およびオプションに関する情報を表示します。

--persist を指定しない場合のクレデンシャルストアの作成例

以下のコマンドはクレデンシャルストアを作成しますが、クレデンシャルストアの設定は ${karaf.etc}/system.properties に保存されません。このコマンドは、デフォルトの masked-SHA1-DES-EDE アルゴリズムを使用します。

karaf@root()> credential-store:create
Credential store password: *****
Credential store password (repeat): *****

Credential store was written to /data/servers/fuse-karaf-7.4.0.fuse-740060/etc/credential.store.p12

By default, only system properties are encrypted.
Encryption of configuration admin properties can be enabled by
setting felix.cm.pm=elytron in etc/config.properties.

Credential store configuration was not persisted and is not
effective. Please use one of the following configuration options and restart Fuse.
Option #1: Configure these system properties (e.g., in etc/system.properties):
 - credential.store.protection.algorithm=masked-SHA1-DES-EDE
 - credential.store.protection.params=MDkEKGdOSkpRWXpndjhkVVZYbHF4elVpbUszNW0wc3NXczhNS1A5cVlhZzcCAwMNQAQIDPzQ+BDGwX4=
 - credential.store.protection=0qudlx1XZFM=
 - credential.store.location=/data/servers/fuse-karaf-7.4.0.fuse-740060/etc/credential.store.p12
Option #2: Configure these environmental variables (e.g., in bin/setenv):
 - CREDENTIAL_STORE_PROTECTION_ALGORITHM=masked-SHA1-DES-EDE
 - CREDENTIAL_STORE_PROTECTION_PARAMS=MDkEKGdOSkpRWXpndjhkVVZYbHF4elVpbUszNW0wc3NXczhNS1A5cVlhZzcCAwMNQAQIDPzQ+BDGwX4=
 - CREDENTIAL_STORE_PROTECTION=0qudlx1XZFM=
 - CREDENTIAL_STORE_LOCATION=/data/servers/fuse-karaf-7.4.0.fuse-740060/etc/credential.store.p12

2.5.5. credential-store:store コマンドリファレンス

暗号化された値をクレデンシャルストアに追加するには、以下の形式の credential-store:store コマンドを実行します。

credential-store:store alias [secret]

alias を一意の鍵値に置き換えます。クレデンシャルストアに追加する暗号化された値を取得するために、ツールでこのエイリアスを使用します。

必要に応じて、secret を暗号化してクレデンシャルストアに追加する値に置き換えます。通常、これはパスワードですが、暗号化する任意の値を指定できます。

コマンドラインで secret を指定すると、プレーンテキストの値が履歴に表示されます。コマンドラインで secret を指定しないと、コマンドによりその入力を求められ、値は履歴に表示されません。

コマンドに関する情報を表示するには、以下を入力します。

credential-store:store --help.

以下のコマンドラインは、エントリーをクレデンシャルストアに追加する例です。

karaf@root()> credential-store:store db.password sec4et
Value stored in the credential store. To reference it use: CS:db.password

クレデンシャルストアには、CS:db.password を指定して参照できるエントリーが含まれるになります。

2.5.6. credential-store:list コマンドリファレンス

クレデンシャルストアのエントリーのエイリアスを取得するには、credential-store:list コマンドを実行します。これにより、クレデンシャルストアのすべてのエントリーのリストが表示されます。以下に例を示します。

karaf@root()> credential-store:list
Alias        │ Reference
─────────────┼───────────────
db.password  │ CS:db.password
db2.password | CS:db2.password

クレデンシャルストアで暗号化されるシークレット値の復号化も一覧表示するには、以下のようにコマンドを実行します。

karaf@root()> credential-store:list --show-secrets
Alias        │ Reference       │ Secret value
─────────────┼─────────────────┼─────────────
db.password  │ CS:db.password  │ sec4et
db2.password | CS:db2.password | t0pSec4et

コマンドに関する情報を表示するには、以下のコマンドを実行します。

karaf@root()> credential-store:list --help

2.5.7. credential-store:remove コマンドリファレンス

クレデンシャルストアからエントリーを削除するには、以下の形式の credential-store:remove コマンドを実行します。

credential-store:remove alias

alias は、エントリーをクレデンシャルストアに追加したときにalias 引数に指定した一意の鍵値に置き換えます。CS: プレフィックスは指定しないでください。credential-store:list コマンドを実行してエイリアスを取得できます。

credential-store:remove コマンドは、指定したエイリアスを持つエントリーのクレデンシャルストアをチェックし、見つかった場合は削除します。以下に例を示します。

karaf@root()> credential-store:remove db.password

Alias        │ Reference       │ Secret value
─────────────┼─────────────────┼─────────────
db2.password | CS:db2.password | t0pSec4et

コマンドに関する情報を表示するには、以下のコマンドを実行します。

karaf@root()> credential-store:remove --help

2.5.8. クレデンシャルストアの使用を有効にする Configuration Admin プロパティーの例

開発環境では、Configuration Admin サービスプロパティーを使用してクレデンシャルストアの使用を有効にできます。Configuration Admin プロパティーは etc/*.cfg ファイルで定義されます。

重要

Configuration Admin プロパティーを使用してクレデンシャルストアの使用を有効にすることは、テクノロジープレビュー機能としてのみご利用いただけます。テクノロジープレビュー機能は、Red Hat の本番環境のサービスレベルアグリーメント (SLA) ではサポートされず、機能的に完全ではないことがあるため、Red Hat は本番環境での使用は推奨しません。Red Hat では、これらについて実稼働環境での使用を推奨していません。テクノロジープレビューの機能は、最新の製品機能をいち早く提供して、開発段階で機能のテストやフィードバックの提供を可能にするために提供されます。Red Hat のテクノロジープレビュー機能のサポート範囲に関する詳細は、https://access.redhat.com/ja/support/offerings/techpreview を参照してください。

準備

  • credential-store:create コマンドを呼び出してクレデンシャルストアを作成します。「credential-store:create command reference」を参照してください。
  • Configuration Admin プロパティーの使用を有効にするには、etc/config.properties ファイルを編集して、felix.cm.pm = elytron が含まれる行のコメントを解除します。
# When uncommented, configuration properties handled by Configuration Admin service will be encrypted when storing
# in etc/ and in bundle data. Values of the properties will actually be aliases to credential store entries.
# Please consult the documentation for more details.
felix.cm.pm = elytron

Fuse 起動時の挙動

  1. felix.configadmin バンドル:

    • felix.cm.pm プロパティーが設定されているため、ConfigurationAdmin サービスの登録が遅延します。
    • name=cm OSGi サービス登録プロパティーで、org.apache.felix.cm.PersistenceManagerOSGi サービスが利用可能になるのを待ちます。
  2. Fuse クレデンシャルストアバンドル:

    1. credential.store.* システムプロパティーまたは CREDENTIAL_STORE_* 環境変数に設定した値を使用して、クレデンシャルストアをロードします。
    2. org.apache.felix.cm.PersistenceManagerOSGi サービスを実装する OSGi サービスを登録します。

    何らかの障害が発生した場合、クレデンシャルストアバンドルは PersistenceManager サービスを登録しますが、特別なことはしません。何かが正常でない場合や、クレデンシャルストアが利用できない場合は、Fuse は暗号化されていない設定値を読み取りできるはずです。CS: プレフィックスで指定した暗号化された値は、元の値を覚えているか、クレデンシャルストアとその設定を復旧できる場合以外は失われます。

  3. felix.configadmin プロセスは、新しい永続マネージャーサービスを使用してクレデンシャルストア設定をロードおよび保存します。

クレデンシャルストアに 2 つのエントリーがあるとします。

karaf@root()> credential-store:list --show-secrets
Alias       │ Reference      │ Secret value
────────────┼────────────────┼─────────────
db.password │ CS:db.password │ sec4et
http.port   │ CS:http.port   │ 8182

Configuration Admin サービス設定で、実際の値の代わりに機密値のエイリアスを使用します。たとえば、以下のように web 設定プロパティーを変更します。

karaf@root()> config:property-list --pid org.ops4j.pax.web
   javax.servlet.context.tempdir = /data/servers/fuse-karaf-7.4.0.fuse-740060/data/pax-web-jsp
   org.ops4j.pax.web.config.file = /data/servers/fuse-karaf-7.4.0.fuse-740060/etc/undertow.xml
   org.ops4j.pax.web.session.cookie.httpOnly = true
   org.osgi.service.http.port = 8181

karaf@root()> config:property-set --pid org.ops4j.pax.web org.osgi.service.http.port CS:http.port

karaf@root()> config:property-list --pid org.ops4j.pax.web
   javax.servlet.context.tempdir = /data/servers/fuse-karaf-7.4.0.fuse-740060/data/pax-web-jsp
   org.ops4j.pax.web.config.file = /data/servers/fuse-karaf-7.4.0.fuse-740060/etc/undertow.xml
   org.ops4j.pax.web.session.cookie.httpOnly = true
   org.osgi.service.http.port = CS:http.port

ログでは、以下の行の最後にあるように、実際の値 8182 が表示されます。ログが実際のテキスト値を示すかどうかは、暗号化された値を消費するコンポーネントによって決定されます。

2019-03-12 15:36:25,648 INFO  {paxweb-config-2-thread-1} (ServerControllerImpl.java:458) : Starting undertow http listener on 0.0.0.0:8182

上記のコマンドでは、プロパティーに数値がありますが、2 番目の config:property-list --pid org.ops4j.pax.web コマンドは 8182 ではなく CS:http.port を表示します。pax-web-undertow プロセスは、このポートで開始します。これは、OSGi フックにより、config:property-list --pid org.ops4j.pax.web コマンドの出力を表示する felix.fileinstall プロセスが、復号化された (逆参照) 値を認識できないようにするためです。これは、etc/org.ops4j.pax.web.cfg ファイルが復号化された (逆参照) 値を格納せず、代わりに格納する理由でもあります。次に例を示します。

org.osgi.service.http.port = CS:http.port

org.ops4j.pax.web.config.file = ${karaf.etc}/undertow.xml
org.ops4j.pax.web.session.cookie.httpOnly = true

javax.servlet.context.tempdir = ${karaf.data}/pax-web-jsp