Apache Karaf セキュリティーガイド

Red Hat Fuse 7.8

Apache Karaf コンテナーのセキュリティー

Red Hat Fuse Documentation Team

概要

本ガイドでは、Red Hat Fuse コンテナー、Web コンソール、メッセージブローカー、ルーティングおよびインテグレーションコンポーネント、Web および RESTful サービスをセキュアにする方法を説明し、LDAP 認証のチュートリアルを提供します。

第1章 セキュリティーアーキテクチャー

概要

OSGi コンテナーでは、さまざまなセキュリティー機能をサポートするアプリケーションをデプロイすることができます。現時点で、Java Authentication and Authorization Service (JAAS) のみが共通のコンテナー全体のインフラストラクチャーに基づいています。その他のセキュリティー機能は、コンテナーにデプロイされる個々の製品およびコンポーネントによって個別に提供されます。

1.1. OSGi コンテナーセキュリティー

概要

図1.1「OSGi コンテナーセキュリティーアーキテクチャー」 は、コンテナー全体で使用され、コンテナーにデプロイされているすべてのバンドルからアクセスできるセキュリティーインフラストラクチャーの概要を表しています。この共通セキュリティーインフラストラクチャーは、現在すべてのアプリケーションバンドルで JAAS レルム (またはログインモジュール) を使用できるようにするためのメカニズムで構成されています。

図1.1 OSGi コンテナーセキュリティーアーキテクチャー

architecture 01

JAAS レルム

JAAS レルムまたはログインモジュールは、Java Authentication and Authorization Service (JAAS) 仕様で定義されているように、Java アプリケーションに認証および承認データを提供するプラグインモジュールです。

Red Hat Fuse は JAAS ログインモジュール (Spring または Blueprint ファイルのいずれか) を定義する特別なメカニズムをサポートします。これにより、ログインモジュールはコンテナーのすべてのバンドルからアクセスできます。これにより、OSGi コンテナーで実行している複数のアプリケーションが、セキュリティーデータを単一の JAAS レルムに統合できるようになります。

Karaf レルム

OSGi コンテナーには、事前定義された JAAS レルムである karaf レルムがあります。Red Hat Fuse は、karaf レルムを使用して、OSGi ランタイムのリモート管理、Fuse 管理コンソール、および JMX 管理の認証を提供します。karaf レルムは、認証データが InstallDir/etc/users.properties ファイルに保存される簡単なファイルベースのリポジトリーを使用します。

独自のアプリケーションで karaf レルムを使用できます。karaf を、使用する JAAS レルムの名前として設定するだけです。その後、アプリケーションは users.properties ファイルからのデータを使用して認証を実行します。

コンソールポート

Karaf クライアントでコンソールポートに接続するか、Karaf ssh:ssh コマンドを使用して、OSGi コンテナーをリモートで管理できます。コンソールポートは、karaf レルムに接続する JAAS ログイン機能によってセキュア化されます。コンソールポートへの接続を試みると、karaf レルムからアカウントのいずれかに一致する必要のあるユーザー名とパスワードの入力が要求されます。

JMX ポート

JMX ポートに接続すると、OSGi コンテナーを管理できます (Java の JConsole を使用するなど)。JMX ポートは、karaf レルムに接続する JAAS ログイン機能によっても保護されます。

アプリケーションバンドルと JAAS セキュリティー

OSGi コンテナーにデプロイするアプリケーションバンドルは、コンテナーの JAAS レルムにアクセスできます。アプリケーションバンドルは、既存の JAAS レルムのいずれかを名前 (JAAS ログインモジュールのインスタンスに対応) で参照するだけです。

ただし、JAAS レルムは OSGi コンテナー独自のログイン設定メカニズムを使用して定義することが不可欠です。デフォルトでは、Java は単純なファイルベースのログイン設定実装を提供しますが、OSGi コンテナーのコンテキストでこの実装を使用することはできません

1.2. Apache Camel のセキュリティー

概要

図1.2「Apache Camel のセキュリティーアーキテクチャー」 に、Apache Camel エンドポイント間でメッセージを安全にルーティングするための基本的なオプションの概要を示します。

図1.2 Apache Camel のセキュリティーアーキテクチャー

architecture 03

Apache Camel セキュリティーの代替

図1.2「Apache Camel のセキュリティーアーキテクチャー」 ので示すように、メッセージのセキュリティーを保護するためのオプションがあります。

  • エンドポイントセキュリティー - パート (a) は、セキュアなエンドポイントを持つ 2 つのルート間で送信されるメッセージを表しています。左側のプロデューサーエンドポイントは、右側のコンシューマーエンドポイントへのセキュアな接続 (通常は SSL/TLS を使用) を開きます。このシナリオでは、両方のエンドポイントがセキュリティーをサポートします。

    エンドポイントセキュリティーでは、通常、ピア認証 (場合によっては承認) の形式を実行できます。

  • ペイロードセキュリティー - パート (b) は、エンドポイントが両方とも安全でないルート間で送信されるメッセージを表しています。この場合、不正なスヌーピングからメッセージを保護するには、メッセージの送信前に暗号化し、受信後に復号化するペイロードプロセッサーを使用します。

    ペイロードセキュリティーの制限は、いかなる種類の認証または承認メカニズムも提供しないことです。

エンドポイントセキュリティー

セキュリティー機能をサポートする複数の Camel コンポーネントがあります。ただし、これらのセキュリティー機能は、Camel コアではなく、個々のコンポーネントによって実装されている点に留意することが重要です。したがって、サポートされるセキュリティー機能の種類や、実装の詳細はコンポーネントによって異なります。現在セキュリティーをサポートする Camel コンポーネントには、以下が含まれます。

  • JMS および ActiveMQ: クライアント対ブローカーおよびブローカー対ブローカーの通信用の SSL/TLS セキュリティーおよび JAAS セキュリティー。
  • Jetty: HTTP Basic Authentication および SSL/TLS セキュリティー。
  • CXF: SSL/TLS セキュリティーおよび WS-Security。
  • Crypto: メッセージの整合性を保証するために、デジタル署名を作成および検証します。
  • Netty: SSL/TLS セキュリティー。
  • MINA: SSL/TLS セキュリティー。
  • Cometd: SSL/TLS セキュリティー。
  • glogin および gauth: Google アプリケーションのコンテキストでの承認。

ペイロードセキュリティー

Apache Camel は、以下のペイロードセキュリティー実装を提供します。この実装では、暗号化手順および復号化手順は marshal() および unmarshal() 操作でデータ形式として公開されます。

XMLSecurity データフォーマット

XMLSecurity データフォーマットは、XML ペイロードを暗号化するために特別に設計されています。このデータフォーマットを使用する場合は、暗号化する XML 要素を指定することができます。デフォルトの動作では、すべての XML 要素を暗号化します。この機能は、対称暗号化アルゴリズムを使用します。

詳細は、http://camel.apache.org/xmlsecurity-dataformat.html を参照してください。

Crypto データフォーマット

crypto データフォーマットは、あらゆる種類のペイロードを暗号化できる汎用暗号化機能です。これは Java Cryptographic Extension をベースとしており、対称 (共有鍵) 暗号化と復号化のみを実装します。

詳細は、hhttp://camel.apache.org/crypto.html を参照してください。

第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.8 の一部である 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

第3章 Undertow HTTP サーバーのセキュア化

概要

etc/undertow.xml 設定ファイルの内容を編集して、組み込み Undertow HTTP サーバーが SSL/TLS セキュリティーを使用するように設定できます。特に、この方法で Fuse Console に SSL/TLS セキュリティーを追加できます。

3.1. Undertow サーバー

Fuse コンテナーは、汎用の HTTP サーバーおよび HTTP サーブレットコンテナーとして動作する Undertow サーバーで事前設定されています。1 つの HTTP ポート (デフォルトでは http://localhost:8181) により、Undertow コンテナーは複数のサービスをホストできます。以下に例を示します。

  • Fuse Console (デフォルトは http://localhost:8181/hawtio)
  • Apache CXF Web サービスエンドポイント (ホストとポートがエンドポイント設定で未指定である場合)
  • 一部の Apache Camel エンドポイント

すべての HTTP エンドポイントにデフォルトの Undertow サーバーを使用する場合は、ここで説明する手順に従って、SSL/TLS セキュリティーをこれらの HTTP エンドポイントに追加できます。

3.2. X.509 証明書と秘密鍵の作成

Undertow サーバーで SSL/TLS を有効にする前に、X.509 証明書と秘密鍵を作成する必要があります。証明書と秘密鍵は Java キーストア形式 (JKS 形式) である必要があります。署名付き証明書および秘密鍵を作成する方法は、付録A 証明書の管理 を参照してください。

3.3. Apache Karaf コンテナーの Undertow における SSL/TLS の有効化

以下の手順では、キーストアパスワード StorePass およびキーパスワード KeyPass で、署名済みの X.509 証明書と秘密鍵のペアがキーストアファイル alice.ksで作成済みであることを前提とします。

Karaf コンテナーで Undertow の SSL/TLS を有効にするには、以下を行います。

  1. Pax Web サーバーが、etc/undertow.xml ファイルから設定を取得するように設定されていることを確認します。etc/org.ops4j.pax.web.cfg ファイルの内容を確認すると、以下の設定があるはずです。

    org.ops4j.pax.web.config.file=${karaf.etc}/undertow.xml
  2. テキストエディターでファイル etc/org.ops4j.pax.web.cfg ファイルを開き、以下の行を追加します。

    org.osgi.service.http.port.secure=8443

    ファイル etc/org.ops4j.pax.web.cfg を保存して閉じます。

  3. テキストエディターで etc/undertow.xml ファイルを開きます。次の手順では、インストール時以降、変更されていないデフォルトの undertow.xml ファイルで作業することを前提としています。
  4. http-listener および https-listener XML 要素を検索します。http-listener 要素をコメントアウトし (<!-- および --> で囲み)、https-listener 要素をアンコメントします (2 行使用)。編集された XML のフラグメントは、次のようになります。

    <!-- HTTP(S) Listener references Socket Binding (and indirectly - Interfaces) -->
    <!-- http-listener name="http" socket-binding="http" /> -->
    <!-- verify-client: org.xnio.SslClientAuthMode.NOT_REQUESTED, org.xnio.SslClientAuthMode.REQUESTED, org.xnio.SslClientAuthMode.REQUIRED -->
    <https-listener name="https" socket-binding="https"
            security-realm="https" verify-client="NOT_REQUESTED" />
  5. w:keystore 要素を検索します。デフォルトでは、w:keystore 要素は以下のように設定されます。

    <w:keystore path="${karaf.etc}/certs/server.keystore" provider="JKS" alias="server"
                keystore-password="secret" key-password="secret"
                generate-self-signed-certificate-host="localhost" />

    Undertow サーバーの証明書として alice 証明書をインストールするには、以下のように w:keystore 要素属性を変更します。

    • path を、ファイルシステムにおける alice.ks ファイルの場所 (絶対パス) に設定します。
    • providerJKS に設定します。
    • alias をキーストアの alice 証明書エイリアスに設定します。
    • keystore-password を、キーストアをアンロックするパスワードの値に設定します。
    • key-password を、alice 秘密鍵を暗号化するパスワードの値に設定します。
    • generate-self-signed-certificate-host 属性設定を削除します。
  6. たとえば、alice.ks キーストアをインストールした後に、変更された w:keystore 要素は以下のようになります。

    <w:keystore path="${karaf.etc}/certs/alice.ks" provider="JKS" alias="alice"
                keystore-password="StorePass" key-password="KeyPass" />
  7. セキュアな HTTPS ポートがバインドする IP アドレスを指定するために使用される <interface name="secure"> タグを検索します。デフォルトでは、この要素は以下のようにコメントアウトされています。

    <!--<interface name="secure">-->
        <!--<w:inet-address value="127.0.0.1" />-->
    <!--</interface>-->

    要素のコメントを解除し、value 属性をカスタマイズして、HTTPS ポートをバインドする IP アドレスを指定します。たとえば、ワイルドカード値 0.0.0.0 は、利用可能なすべての IP アドレスにバインドするように HTTPS を設定します。

    <interface name="secure">
        <w:inet-address value="0.0.0.0" />
    </interface>
  8. <socket-binding name="https" タグを検索し、コメントを解除します。このタグのコメントが解除されると、以下のようになります。

    <socket-binding name="https" interface="secure" port="${org.osgi.service.http.port.secure}" />
  9. ファイル etc/undertow.xml を保存して閉じます。
  10. 設定の変更を有効にするために、Fuse コンテナーを再起動します。

3.4. 許可される TLS プロトコルおよび暗号スイートのカスタマイズ

許可される TLS プロトコルおよび暗号スイートをカスタマイズするには、etc/undertow.xml ファイルの w:engine 要素の以下の属性を変更します。

enabled-cipher-suites
許可される TLS/SSL 暗号スイートのリストを指定します。
enabled-protocols

許可される TLS/SSL プロトコルのリストを指定します。

警告

SSL プロトコルバージョンは攻撃に対して脆弱であるため、有効にしないでください。TLS プロトコルバージョンのみを使用します。

使用可能なプロトコルと暗号スイートの詳細については、該当する JVM のドキュメントおよびセキュリティープロバイダーのドキュメントを参照してください。たとえば、Java 8 の場合は、「Java Cryptography Architecture Oracle Providers Documentation for JDK 8」を参照してください。

3.5. セキュアなコンソールへの接続

Pax Web 設定ファイルで Undertow サーバーの SSL セキュリティーを設定したら、以下の URL に移動して Fuse Console を開くことができるはずです。

https://localhost:8443/hawtio
注記

この URL では、http: ではなく、https: スキームを入力するようにしてください。

最初に、ブラウザーは信頼できない証明書を使用していることを警告します。この警告をスキップすると、Fuse Console のログイン画面が表示されます。

3.6. 高度な Undertow 設定

3.6.1. IO の設定

PAXWEB-1255 以降、リスナーによって使用される XNIO ワーカーおよびバッファープールの設定を変更できます。undertow.xml テンプレートには、一部の IO 関連のパラメーターのデフォルト値を指定するセクションがあります。

<!-- Only "default" worker and buffer-pool are supported and can be used to override the default values used by all listeners
    buffer-pool:
     - buffer-size defaults to:
        - when < 64MB of Xmx: 512
        - when < 128MB of Xmx: 1024
        - when >= 128MB of Xmx: 16K - 20
     - direct-buffers defaults to:
        - when < 64MB of Xmx: false
        - when >= 64MB of Xmx: true
    worker:
     - io-threads defaults to Math.max(Runtime.getRuntime().availableProcessors(), 2);
     - task-core-threads and task-max-threads default to io-threads * 8
-->

<!--
<subsystem xmlns="urn:jboss:domain:io:3.0">
    <buffer-pool name="default" buffer-size="16364" direct-buffers="true" />
    <worker name="default" io-threads="8" task-core-threads="64" task-max-threads="64" task-keepalive="60000" />
</subsystem>
-->

以下の buffer-pool パラメーターを指定できます。

buffer-size
IO 操作に使用されるバッファーのサイズを指定します。指定のない場合は、利用可能なメモリーに応じてサイズが計算されます。
direct-buffers
java.nio.ByteBuffer#allocateDirect または java.nio.ByteBuffer#allocate を使用するかどうかを決定します。

以下の worker パラメーターを指定できます。

io-threads
ワーカー用に作成する I/O スレッドの数。指定のない場合は、スレッド数は CPU の数の 2 倍に設定されます。
task-core-threads
コアタスクスレッドプールのスレッド数。
task-max-threads
ワーカータスクスレッドプールの最大スレッド数。指定のない場合は、最大スレッド数は CPU の数の 16 倍に設定されます。

第4章 Camel ActiveMQ コンポーネントのセキュア化

概要

Camel ActiveMQ コンポーネントを使用すると、Apache ActiveMQ ブローカーに接続できるルートに JMS エンドポイントを定義できます。Camel ActiveMQ エンドポイントをセキュアにするには、セキュアな接続ファクトリーを使用する Camel ActiveMQ コンポーネントのインスタンスを作成する必要があります。

4.1. Secure ActiveMQ 接続ファクトリー

概要

Apache Camel は、ルートで Apache ActiveMQ エンドポイントを定義するための Apache ActiveMQ コンポーネントを提供します。Apache ActiveMQ エンドポイントはブローカーの Java クライアントです。また、コンシューマーエンドポイント (通常は JMS メッセージをポーリングするためルートの開始時に使用される) か、プロデューサーエンドポイント (通常は JMS メッセージをブローカーに 送信するルートの最後または途中で使用される) のいずれかを定義できます。

リモートブローカーがセキュア (SSL セキュリティー、JAAS セキュリティー、または両方) な場合、Apache ActiveMQ コンポーネントを必要なクライアントセキュリティー設定で設定する必要があります。

セキュリティープロパティーのプログラミング

Apache ActiveMQ では、ActiveMQSslConnectionFactory JMS 接続ファクトリーのインスタンスを作成および設定することで、SSL セキュリティー設定 (および JAAS セキュリティー設定) をプログラムできます。JMS 接続ファクトリーのプログラミングは、OSGi、J2EE、Tomcat などのコンテナーのコンテキストで使用する正しいアプローチです。これらの設定は JMS 接続ファクトリーインスタンスを使用するアプリケーションのローカル設定であるためです。

注記

スタンドアロンブローカーは、Java システムプロパティーを使用して SSL を設定できます。ただし、コンテナーにデプロイされたクライアントの場合、この設定は OSGi コンテナー全体ではなく、個別のバンドルのみに適用される必要があるため、実用的なアプローチではありません。Camel ActiveMQ エンドポイントは事実上一種の Apache ActiveMQ Java クライアントであるため、この制限は Camel ActiveMQ エンドポイントにも適用されます。

セキュアな接続ファクトリーの定義

例4.1「セキュアな接続ファクトリー Bean の定義」 は、Blueprint でセキュアな接続ファクトリー Bean を作成し、SSL/TLS セキュリティー JAAS 認証の両方を有効にする方法を表しています。

例4.1 セキュアな接続ファクトリー Bean の定義

<bean id="jmsConnectionFactory"
      class="org.apache.activemq.ActiveMQSslConnectionFactory">
  <property name="brokerURL" value="ssl://localhost:61617" />
  <property name="userName" value="Username"/>
  <property name="password" value="Password"/>
  <property name="trustStore" value="/conf/client.ts"/>
  <property name="trustStorePassword" value="password"/>
</bean>

以下のプロパティーは ActiveMQSslConnectionFactory クラスで指定されます。

brokerURL
接続するリモートブローカーの URL。この例ではローカルホストの SSL 対応 OpenWire ポートに接続します。ブローカーは、互換性のあるポート設定を持つ対応するトランスポートコネクターを定義する必要もあります。
userName および password
有効な JAAS ログインクレデンシャル、Username および Password
trustStore
SSL 接続の証明書トラストストアが含まれる Java キーストアファイルの場所。場所はクラスパスリソースとして指定されます。相対パスを指定すると、リソースの場所はクラスパスの org/jbossfuse/example ディレクトリーからの相対パスになります。
trustStorePassword
トラストストアが含まれるキーストアファイルのロックを解除するパスワード。

keyStore および keyStorePassword プロパティーを指定することもできますが、これらのプロパティーは、SSL 相互認証が有効になっている場合にのみ必要になります (クライアントが SSL ハンドシェイク中に X.509 証明書をブローカーに提示)。

4.2. Camel ActiveMQ コンポーネントの設定例

概要

本セクションでは、Camel ルートで ActiveMQ エンドポイントを定義するために使用できる Camel ActiveMQ コンポーネントインスタンスのサンプルを初期化および設定する方法を説明します。これにより、Camel ルートがブローカーからメッセージを送受信できます。

前提条件

Camel ActiveMQ コンポーネントに必要なバンドルを定義する camel-activemq 機能は、デフォルトではインストールされませんcamel-activemq 機能をインストールするには、以下のコンソールコマンドを入力します。

JBossFuse:karaf@root> features:install camel-activemq

Camel ActiveMQ コンポーネントのサンプル

以下の Blueprint の例は、SSL/TLS セキュリティーと JAAS 認証の両方が有効になっている Camel ActiveMQ コンポーネントの完全な設定を示しています。Camel ActiveMQ コンポーネントインスタンスは activemqssl Bean ID と定義されます。つまり、Camel ルート内でエンドポイントを定義するときに使用する activemqssl スキームに関連付けられています。

<?xml version="1.0" encoding="UTF-8"?>
<beans ... >
  ...
  <!--
    Configure the activemqssl component:
  -->
  <bean id="jmsConnectionFactory"
        class="org.apache.activemq.ActiveMQSslConnectionFactory">
    <property name="brokerURL" value="ssl://localhost:61617" />
    <property name="userName" value="Username"/>
    <property name="password" value="Password"/>
    <property name="trustStore" value="/conf/client.ts"/>
    <property name="trustStorePassword" value="password"/>
  </bean>

  <bean id="pooledConnectionFactory"
        class="org.apache.activemq.pool.PooledConnectionFactory">
    <property name="maxConnections" value="8" />
    <property name="maximumActive" value="500" />
    <property name="connectionFactory" ref="jmsConnectionFactory" />
  </bean>

  <bean id="jmsConfig" class="org.apache.camel.component.jms.JmsConfiguration">
    <property name="connectionFactory" ref="pooledConnectionFactory"/>
    <property name="transacted" value="false"/>
    <property name="concurrentConsumers" value="10"/>
  </bean>

  <bean id="activemqssl"
        class="org.apache.activemq.camel.component.ActiveMQComponent">
    <property name="configuration" ref="jmsConfig"/>
  </bean>

</beans>

Camel ルートの例

以下の Camel ルートは、前述の例で定義された Camel ActiveMQ コンポーネントを参照する activemqssl スキームを使用して、ブローカーの security.test キューにメッセージを安全に送信するサンプルエンドポイントを定義します。

<?xml version="1.0" encoding="UTF-8"?>
<beans ...>
  ...
  <camelContext xmlns="http://camel.apache.org/schema/spring">
    <route>
      <from uri="timer://myTimer?fixedRate=true&period=5000"/>
      <transform><constant>Hello world!</constant></transform>
      <to uri="activemqssl:security.test"/>
    </route>
  </camelContext>
  ...
</beans>

第5章 Camel CXF コンポーネントのセキュア化

概要

本章では、Camel CXF プロキシーのデモンストレーションを開始点として使用して、Camel CXF エンドポイントで SSL/TLS セキュリティーを有効にする方法を説明します。Camel CXF コンポーネントを使用すると、Apache CXF エンドポイントを Apache Camel ルートに追加できます。これにより、Apache Camel で Web サービスをシミュレートでき、WS クライアントと Web サービスとの間のルートに割り込み、追加の処理 (ここで考慮される) を実行することもできます。

5.1. Camel CXF プロキシーのデモンストレーション

概要

OSGi で Camel CXF エンドポイントを保護する方法を説明するために、このチュートリアルは、Camel CXF プロキシーデモンストレーションである Apache Camel のスタンドアロンディストリビューションから入手できる例に構築されます。図5.1「Camel CXF プロキシーの概要」 はこのデモの仕組みの概要を示しています。

図5.1 Camel CXF プロキシーの概要

camel cxf 01

RealWebServiceBean によって実装されたレポートインシデント Web サービスは、インシデント (例: 交通事故) の詳細を受信し、クライアントに追跡コードを返します。ただし、WS クライアントはリクエストを実際の Web サービスに直接送信するのではなく、WS クライアントと実際の Web サービスとの間に割り込まれる Camel CXF エンドポイントに接続します。Apache Camel ルートは (enrichBean を使用して) WSDL メッセージに何らかの処理を実行した後に実際の Web サービスに転送します。

警告

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

変更

OSGi のコンテキストで Camel CXF エンドポイントの SSL/TLS を有効にする方法を示すために、この章では、基本的なデモンストレーションを次のように変更する方法について説明します。

  1. WS クライアントと Camel CXF エンドポイントとの間の接続で SSL/TLS セキュリティーが有効になります。
  2. Apache Camel ルートと RealWebServiceBean Bean の両方が OSGi コンテナーにデプロイされます。

デモンストレーションコードの取得

Camel CXF プロキシーのデモンストレーションは、InstallDir/extras ディレクトリーに含まれる Apache Camel のスタンドアロンディストリビューションでのみ利用可能です。標準のアーカイブユーティリティーを使用して Camel アーカイブファイルを展開し、ファイルシステムの便利な場所にコンテンツを抽出します。

Apache Camel を CamelInstallDir にインストールしている場合、以下のディレクトリーに Camel CXF プロキシーのデモンストレーションがあります。

CamelInstallDir/examples/camel-example-cxf-proxy

サンプル証明書の取得

このデモンストレーションには X.509 証明書が必要です。実際のデプロイメントでは、プライベート認証局を使用してこれらの証明書を独自に生成する必要があります。ただし、このデモでは、Apache CXF の wsdl_first_http の例からいくつかのサンプル証明書を使用します。このデモは、InstallDir/extras ディレクトリーに含まれる Apache CXF のスタンドアロンディストリビューションから入手できます。標準のアーカイブユーティリティーを使用して CXF アーカイブファイルを展開し、ファイルシステムの便利な場所にコンテンツを抽出します。

Apache CXF を CXFInstallDir にインストールしている場合、以下のディレクトリーに wsdl_first_http デモンストレーションがあります。

CXFInstallDir/samples/wsdl_first_http

WSDL コントラクトの物理部分

WSDL コントラクトの物理部分は、wsdl:service および wsdl:port 要素を参照します。これらの要素は、特定の Web サービスエンドポイントに接続するために必要なトランスポートの詳細を指定します。このデモの目的では、これがコントラクトで最も興味深い部分で、例5.1「ReportIncidentEndpointService WSDL サービス」 に示されています。

例5.1 ReportIncidentEndpointService WSDL サービス

<wsdl:definitions xmlns:soap="http://schemas.xmlsoap.org/wsdl/soap/"
    ...
	xmlns:wsdl="http://schemas.xmlsoap.org/wsdl/"
	targetNamespace="http://reportincident.example.camel.apache.org">
    ...
    <!-- Service definition -->
    <wsdl:service name="ReportIncidentEndpointService">
        <wsdl:port name="ReportIncidentEndpoint" binding="tns:ReportIncidentBinding">
            <soap:address location="http://localhost:9080/camel-example-cxf-proxy/webservices/incident"/>
        </wsdl:port>
    </wsdl:service>

</wsdl:definitions>
注記

WSDL コントラクトに表示されるアドレス URL ( soap:address 要素の location 属性の値) は、アプリケーションコードがアドレス URL のデフォルト値を上書きするため、ここでは重要ではありません。

WSDL アドレッシングの詳細

WS クライアントには、WSDL サービスに接続するための 3 つの情報が必要です。これらは WSDL サービス名WSDL ポート名、および Web サービスのアドレス URL です。この例では、プロキシ Web サービスおよび実際の Web サービスへの接続には、次のアドレッシングの詳細が使用されます。

WSDL サービス名

WSDL サービスの完全な QName は以下のとおりです。

{http://reportincident.example.camel.apache.org}ReportIncidentEndpointService
WSDL ポート名

WSDL ポートの完全な QName は以下のとおりです。

{http://reportincident.example.camel.apache.org}ReportIncidentEndpoint
アドレス URL

プロキシー Web サービスエンドポイント (HTTPS プロトコルを使用する) のアドレス URL は以下のとおりです。

https://localhost:9080/camel-example-cxf-proxy/webservices/incident
注記

reportIncident Bean がバンドルの Spring 設定ファイル src/main/resources/META-INF/spring/camel-config.xmlcxf:cxfEndpoint 要素を使用して作成されると、前述のアドレスが指定されます。

実際の Web サービスエンドポイント (HTTP プロトコルを使用) のアドレス URL は以下のとおりです。

http://localhost:9081/real-webservice
注記

realWebService Bean がバンドルの Spring 設定ファイル src/main/resources/META-INF/spring/camel-config.xml で作成されると、前述のアドレスが指定されます。

5.2. Web サービスプロキシーのセキュア化

概要

本セクションでは、実際の Web サービスのプロキシーとして機能する Camel CXF エンドポイントで SSL/TLS セキュリティーを有効にする方法を説明します。X.509 証明書をすでに利用できる場合、必要なのは設定データのブロックを Spring 設定ファイル (設定データは httpj:engine-factory 要素に含まれる) に追加することだけです。ただし、これには少しだけ微妙な側面があります。Camel CXF エンドポイントが SSL/TLS 設定の詳細にどのように関連付けられるかを理解する必要があります。

暗黙的な設定

WS エンドポイントを設定するには、Spring でエンドポイントを作成し、その Jetty コンテナーで SSL/TLS プロパティーを設定します。しかし、設定が若干複雑になることもあります。Jetty コンテナー (Spring の httpj:engine-factory 要素によって設定される) は、含まれる WS エンドポイントを明示的に参照せず、WS エンドポイントは Jetty コンテナーを明示的に参照しないからです。Jetty コンテナーとそれに含まれるエンドポイント間の接続は暗黙的に確立され、いずれも httpj:engine-factory によって暗黙的に設定される WS エンドポイント に示されるように、同じ TCP ポートを使用するよう設定されます。

httpj:engine-factory によって暗黙的に設定される WS エンドポイント

Element

camel cxf 03

Web サービスエンドポイントと httpj:engine-factory 要素間の接続は、以下のように確立されます。

  1. Spring コンテナーは httpj:engine-factory 要素を含むファイルをロードおよび解析します。
  2. httpj:engine-factory Bean が作成されると、対応するエントリーがレジストリーに作成され、Bean への参照が格納されます。httpj:engine-factory Bean は、指定の TCP ポートをリッスンする Jetty コンテナーを初期化するために使用されます。
  3. WS エンドポイントが作成されると、レジストリーをスキャンし、エンドポイントのアドレス URL の TCP ポートと同じ TCP ポートを持つ httpj:engine-factory Bean を検索できるかどうかを確認します。
  4. Bean の 1 つがエンドポイントの TCP ポートと一致する場合、WS エンドポイントは対応する Jetty コンテナーにインストールされます。Jetty コンテナーの SSL/TLS が有効になっている場合、WS エンドポイントはこれらのセキュリティー設定を共有します。

Jetty コンテナーに SSL/TLS セキュリティーを追加する手順

Jetty コンテナーに SSL/TLS セキュリティーを追加し、WS プロキシーエンドポイントをセキュアにするには、以下の手順を実行します。

証明書のバンドルリソースへの追加

このデモンストレーションで使用される証明書は、Apache CXF 3.3.6.fuse-780029-redhat-00001 製品のサンプルから取得されます。スタンドアロンバージョンの Apache CXF (InstallDir/extras/ ディレクトリーで利用可能) をインストールする場合は、CXFInstallDir/samples/wsdl_first_https/src/main/config ディレクトリーにサンプル証明書があります。

clientKeystore.jks および serviceKeystore.jks キーストアを CXFInstallDir/samples/wsdl_first_https/src/main/config ディレクトリーから CamelInstallDir/examples/camel-example-cxf-proxy/src/main/resources/certs ディレクトリーにコピーします (最初に certs サブディレクトリーを作成する必要があります)。

POM の変更によるリソースフィルタリングのオフへの切り替え

リソースとして証明書を直接バンドルに含めることは、デプロイする最も便利な方法です。ただし、証明書を Maven プロジェクトのリソースとしてデプロイする場合は、バイナリーファイルが破損するため、Maven リソースのフィルターを無効にすることを忘れないようにしてください。

Maven で .jks ファイルのフィルタリングを無効にするには、テキストエディターでプロジェクト POM ファイル CamelInstallDir/examples/camel-example-cxf-proxy/pom.xml を開き、以下の resources 要素を build 要素の子として追加します。

<?xml version="1.0" encoding="UTF-8"?>
...
<project ...>
  ...
  <build>
    <plugins>
      ...
    </plugins>

    <resources> <resource> <directory>src/main/resources</directory> <filtering>true</filtering> <excludes> <exclude>/.jks</exclude> </excludes> </resource> <resource> <directory>src/main/resources</directory> <filtering>false</filtering> <includes> <include>/.jks</include> </includes> </resource> </resources>
  </build>

</project>

CXF バスのインスタンス化

Spring XML で明示的に CXF バスをインスタンス化する必要があります (これは、次の手順の httpj:engine-factory 要素によってインスタンス化される Jetty コンテナーが利用できるようにするためです)。src/main/resources/META-INF/spring ディレクトリーの camel-config.xml ファイルを編集し、以下のように cxfcore:bus 要素を beans 要素の子として追加します。

<beans ... >
    ...
    <cxfcore:bus/>
    ...
</beans>
注記

cxfcore: namespace のプレフィックスは、後のステップで定義します。

httpj:engine-factory 要素の Spring への追加

configuration

TCP ポート 9080 でリッスンする Jetty コンテナーを設定するには、src/main/resources/META-INF/spring ディレクトリーの camel-config.xml ファイルを編集し、例5.2「SSL/TLS が有効な httpj:engine-factory 要素」 に示されているように httpj:engine-factory 要素を追加します。

この例では、sec:clientAuthentication 要素の required 属性は false に設定されています。つまり、SSL/TLS ハンドシェイク中に、サーバーに X.509 証明書を提示する必要はありません (ただし、証明書がある場合は提示できます)。

例5.2 SSL/TLS が有効な httpj:engine-factory 要素

<beans ... >
    ...
    <httpj:engine-factory bus="cxf">
      <httpj:engine port="${proxy.port}">
        <httpj:tlsServerParameters secureSocketProtocol="TLSv1">
          <sec:keyManagers keyPassword="skpass">
            <sec:keyStore resource="certs/serviceKeystore.jks" password="sspass" type="JKS"/>
          </sec:keyManagers>
          <sec:trustManagers>
            <sec:keyStore resource="certs/serviceKeystore.jks" password="sspass" type="JKS"/>
          </sec:trustManagers>
          <sec:cipherSuitesFilter>
            <sec:include>.*_WITH_3DES_.*</sec:include>
            <sec:include>.*_WITH_DES_.*</sec:include>
            <sec:exclude>.*_WITH_NULL_.*</sec:exclude>
            <sec:exclude>.*_DH_anon_.*</sec:exclude>
          </sec:cipherSuitesFilter>
          <sec:clientAuthentication want="true" required="false"/>
        </httpj:tlsServerParameters>
      </httpj:engine>
    </httpj:engine-factory>

</beans>
重要

Poodle 脆弱性 (CVE-2014-3566) から保護するために、サーバー側で secureSocketProtocol を TLSv1 に設定する必要があります。

cxfcore:、sec:、および httpj: プレフィックスの定義

camel-config.xml ファイルの beans 要素に、以下の強調表示されている行を追加することで、cxfcore:bus 要素と httpj:engine-factory 要素の定義に表示される cxfcore:sec:、および httpj: namespace プレフィックスを定義します。

<beans xmlns="http://www.springframework.org/schema/beans"
       xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
       xmlns:camel="http://camel.apache.org/schema/spring"
       xmlns:cxf="http://camel.apache.org/schema/cxf"
       xmlns:context="http://www.springframework.org/schema/context"
       xmlns:cxfcore="http://cxf.apache.org/core"
       xmlns:sec="http://cxf.apache.org/configuration/security"
       xmlns:httpj="http://cxf.apache.org/transports/http-jetty/configuration"
       xsi:schemaLocation="
       http://www.springframework.org/schema/beans http://www.springframework.org/schema/beans/spring-beans.xsd
       http://camel.apache.org/schema/spring http://camel.apache.org/schema/spring/camel-spring.xsd
       http://camel.apache.org/schema/cxf http://camel.apache.org/schema/cxf/camel-cxf.xsd
       http://www.springframework.org/schema/context http://www.springframework.org/schema/context/spring-context.xsd
       http://cxf.apache.org/core http://cxf.apache.org/schemas/core.xsd
       http://cxf.apache.org/configuration/security http://cxf.apache.org/schemas/configuration/security.xsd
       http://cxf.apache.org/transports/http-jetty/configuration http://cxf.apache.org/schemas/configuration/http-jetty.xsd
       ">
注記

xsi:schemaLocation 属性で http://cxf.apache.org/configuration/security スキーマと http://cxf.apache.org/transports/http-jetty/configuration スキーマの場所を指定することが不可欠です。これらは OSGi コンテナーによって自動的に提供されません。

HTTPS を使用するようにプロキシーアドレス URL を変更

Apache Camel ルートの最初にあるプロキシーエンドポイントは、camel-config.xml ファイルの cxf:cxfEndpoint 要素によって設定されます。デフォルトでは、このプロキシーエンドポイントは HTTP プロトコルを使用するように設定されます。ただし、セキュアな HTTPS プロトコルを使用するようにアドレス URL を変更する必要があります。camel-config.xml ファイルで、以下のフラグメントが示すように、cxf:cxfEndpoint 要素の address 属性を編集し、http: プレフィックスを https: プレフィックスに置き換えます。

<beans ...>
    ...
    <cxf:cxfEndpoint id="reportIncident"
                     address="https://localhost:${proxy.port}/camel-example-cxf-proxy/webservices/incident"
                     endpointName="s:ReportIncidentEndpoint"
                     serviceName="s:ReportIncidentEndpointService"
                     wsdlURL="etc/report_incident.wsdl"
                     xmlns:s="http://reportincident.example.camel.apache.org"/>
    ...
</beans>

また、アドレス URL は TCP ポート ${proxy.port} を使用するように設定されています (デフォルト値は 9080) 。この TCP ポート値は Jetty コンテナーに設定された値と同じであるため (http:engine-factory 要素によって設定)、このエンドポイントが Jetty コンテナーにデプロイされるようにします。cxf:cxfEndpoint の属性は、「WSDL アドレッシングの詳細」 の説明にあるように、WSDL アドレッシングの詳細を指定します。

serviceName
WSDL サービス名を指定します。
endpointName
WSDL ポート名を指定します。
address
プロキシー Web サービスのアドレス URL を指定します。

5.3. Apache Camel ルートのデプロイ

概要

基本的な Camel CXF プロキシーのデモンストレーションの Maven POM ファイルは、OSGi バンドルを生成するためにすでに設定されています。そのため、Maven を使用してデモンストレーションをビルドした後、Apache Camel ルートと RealWebServicesBean Bean が含まれるデモンストレーションバンドルを OSGi コンテナーにデプロイする準備が整います。

前提条件

Apache Camel ルートを OSGi コンテナーにデプロイする前に、前セクション 「Web サービスプロキシーのセキュア化」 の説明どおりに SSL/TLS セキュリティーを使用するようにプロキシー Web サービスを設定する必要があります。

Camel ルートのデプロイ手順

Web サービスプロキシーのデモンストレーションを OSGi コンテナーにデプロイするには、以下の手順を実行します。

デモンストレーションの構築

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

mvn install -Dmaven.test.skip=true

OSGi コンテナーの起動

まだ起動していない場合は、新しいコマンドプロンプトに以下のコマンドを入力して、Karaf コンソール (およびコンテナーインスタンス) を起動します。

./fuse

必要な機能のインストール

Camel/CXF コンポーネントに必要なバンドルを定義する camel-cxf 機能は、デフォルトではインストールされませんcamel-cxf 機能をインストールするには、以下のコンソールコマンドを入力します。

JBossFuse:karaf@root> features:install camel-cxf

また、Camel/HTTP コンポーネントに必要なバンドルを定義する camel-http 機能も必要です。camel-http 機能をインストールするには、以下のコンソールコマンドを入力します。

JBossFuse:karaf@root> features:install camel-http

バンドルのデプロイ

以下のコンソールコマンドを入力して camel-example-cxf-proxy バンドルをデプロイします。

JBossFuse:karaf@root> install -s mvn:org.apache.camel/camel-example-cxf-proxy/2.23.2.fuse-780036-redhat-00001
注記

この場合、コンソール画面でバンドル出力を確認できるように、ホットデプロイではなく、install を使用してバンドルを直接デプロイすることが推奨されます。

mvn URL ハンドラーの使用に問題がある場合は、設定方法の詳細を「olink: esbosguide/urlHandlers-Maven」で確認してください。

コンソールの出力の確認

バンドルが正常にデプロイされると、コンソールウィンドウに以下のような出力が表示されます。

JBossFuse:karaf@root> Starting real web service...
Started real web service at: http://localhost:9081/real-webservice

5.4. Web サービスクライアントのセキュア化

概要

基本的な Camel CXF プロキシーのデモンストレーションでは、Web サービスクライアントは実際には src/test ディレクトリーに JUnit テストとして実装されます。そのため、クライアントは Maven コマンド mvn test を使用して簡単に実行できます。クライアントで SSL/TLS セキュリティーを有効にするため、テストクライアントの Java 実装が完全に置き換えられ、SSL/TLS 設定を含む Spring ファイルが src/test/resources/META-INF/spring ディレクトリーに追加されます。クライアントのセットアップに必要なステップを説明する前に、このセクションではクライアントの Java コードと Spring 設定の詳細を一部説明します。

暗黙的な設定

エンドポイントアドレスの URL スキームを https: に変更する以外に、クライアントプロキシーで SSL/TLS セキュリティーを有効にする設定のほとんどは、Spring 設定の http:conduit 要素に含まれます。ただし、この設定をクライアントプロキシーに適用する方法は、混乱を招く可能性があります。それは、http:conduit 要素によってクライアントプロキシーが明示的に参照されず、クライアントプロキシーは http:conduit 要素を明示的に参照しないためです。http:conduit 要素とクライアントプロキシー間の接続は暗黙的に確立され、http: conduit によって暗黙的に設定されたクライアントプロキシー が示すように、いずれも同じ WSDL ポートを参照します。

http: conduit によって暗黙的に設定されたクライアントプロキシー

Element

camel cxf 02

以下のように、クライアントプロキシーと http:conduit 要素間の接続が確立されます。

  1. クライアントは http:conduit 要素が含まれる Spring 設定ファイルをロードおよび解析します。
  2. http:conduit Bean が作成されると、対応するエントリーがレジストリーに作成されます。これは、指定の WSDL ポート名の下に Bean への参照を保存します (名前は QName 形式で保存されます)。
  3. JAX-WS クライアントプロキシーが作成されると、レジストリーをスキャンし、プロキシーの WSDL ポート名に関連付けられた http:conduit Bean を見つけられるかどうかを確認します。このような Bean を見つけると、設定の詳細が自動的にプロキシーに注入されます。

クライアント側で必要な証明書

クライアントは、src/main/resources/certs ディレクトリーの以下の clientKeystore.jks キーストアファイルで設定されます。このキーストアには、次の 2 つのエントリーが含まれています。

信頼できる証明書エントリー
サーバー証明書およびクライアント証明書の両方を発行および署名した CA 証明書が含まれる信頼できる証明書エントリー。
プライベートキーエントリー
クライアント独自の X.509 証明書と秘密鍵が含まれる秘密鍵エントリー。実際、TLS ハンドシェイク時にサーバーはクライアントによる証明書の送信を必要としないため、この証明書は現在のサンプルを実行するために厳密には必要はありません (例5.2「SSL/TLS が有効な httpj:engine-factory 要素」 を参照してください)。

Spring 定義のクライアントへのロード

クライアントサンプルは Spring コンテナーに直接デプロイされませんが、セキュアな HTTP コンジットを定義するためには、Spring 定義が一部必要になります。そのため、Spring コンテナーなしで Spring 定義を作成する方法を説明します。org.apache.cxf.bus.spring.SpringBusFactory クラスを使用すると、Spring 定義を Java ベースのクライアントに簡単に読み取ることができます。

以下のコードは、META-INF/spring/cxf-client.xml ファイルから Spring 定義を読み取り、これらの定義を取り入れた Apache CXF Bus オブジェクトを作成する方法を示しています。

// Java
import org.apache.cxf.bus.spring.SpringBusFactory;
...
protected void startCxfBus() throws Exception {
    bf = new SpringBusFactory();
    Bus bus = bf.createBus("META-INF/spring/cxf-client.xml");
    bf.setDefaultBus(bus);
}

クライアントプロキシーの作成

原則として、WSDL プロキシーの作成にはいくつかの方法があります。JAX-WS API を使用して WSDL ファイルの内容に基づいてプロキシーを作成したり、WS-WS API を使用して WSDL ファイルなしでプロキシーを作成できます。また、Apache CXF 固有のクラス JaxWsProxyFactoryBean を使用してプロキシーを作成できます。

この SSL/TLS クライアントの場合、以下の Java の例のように、WSDL ファイルを使用せずに JAX-WS API を使用してプロキシーを作成することが最も便利な方法です。

// Java
import javax.xml.ws.Service;
import org.apache.camel.example.reportincident.ReportIncidentEndpoint;
...
// create the webservice client and send the request
Service s = Service.create(SERVICE_NAME);
s.addPort(
    PORT_NAME,
    "http://schemas.xmlsoap.org/soap/",
    ADDRESS_URL
  );
ReportIncidentEndpoint client =
  s.getPort(PORT_NAME, ReportIncidentEndpoint.class);
注記

この例では、JaxWsProxyFactoryBean のアプローチを使用してプロキシーを作成できません。これは、このように作成されたプロキシーは Spring 設定ファイルで指定された HTTP コンジット設定を見つけることができないためです。

SERVICE_NAME および PORT_NAME 定数は、例5.1「ReportIncidentEndpointService WSDL サービス」 で定義されているように、それぞれ WSDL サービスおよび WSDL ポートの QNames です。ADDRESS_URL 文字列には、プロキシー Web サービスアドレスと同じ値があり、以下のように定義されます。

private static final String ADDRESS_URL =
  "https://localhost:9080/camel-example-cxf-proxy/webservices/incident";

特に、このアドレスは URL スキーム https で定義し、SSL/TLS 経由の HTTP を選択する必要があることに注意してください

クライアントに SSL/TLS セキュリティーを追加する手順

SSL/TLS セキュリティーを有効にして JAX-WS クライアントを定義するには、以下の手順を実行します。

Java クライアントをテストケースとして作成します。

例5.3「ReportIncidentRoutesTest Java client」 は、JUnit テストケースとして実装される Java クライアントの完全なコードを示しています。このクライアントは、examples/camel-example-cxf-proxy デモンストレーションの src/test/java/org/apache/camel/example/reportincident サブディレクトリーの既存のテストである ReportIncidentRoutesTest.java を置き換えます。

クライアントを CamelInstallDir/examples/camel-example-cxf-proxy デモンストレーションに追加するには、src/test/java/org/apache/camel/example/reportincident サブディレクトリーに移動し、既存の ReportIncidentRoutesTest.java ファイルをバックアップの場所に移動し、新しい ReportIncidentRoutesTest.java ファイルを作成し、例5.3「ReportIncidentRoutesTest Java client」 からこのファイルにコードを貼り付けます。

例5.3 ReportIncidentRoutesTest Java client

// Java
package org.apache.camel.example.reportincident;

import org.apache.camel.spring.Main;
import org.apache.cxf.jaxws.JaxWsProxyFactoryBean;
import org.junit.Test;

import java.net.URL;
import javax.xml.namespace.QName;
import javax.xml.ws.Service;

import org.apache.cxf.Bus;
import org.apache.cxf.bus.spring.SpringBusFactory;
import org.apache.camel.example.reportincident.ReportIncidentEndpoint;
import org.apache.camel.example.reportincident.ReportIncidentEndpointService;

import static org.junit.Assert.assertEquals;

/**
 * Unit test of our routes
 */
public class ReportIncidentRoutesTest {

    private static final QName SERVICE_NAME
        = new QName("http://reportincident.example.camel.apache.org", "ReportIncidentEndpointService");

    private static final QName PORT_NAME =
        new QName("http://reportincident.example.camel.apache.org", "ReportIncidentEndpoint");

    private static final String WSDL_URL = "file:src/main/resources/etc/report_incident.wsdl";

    // should be the same address as we have in our route
    private static final String ADDRESS_URL = "https://localhost:9080/camel-example-cxf-proxy/webservices/incident";

    protected SpringBusFactory bf;

    protected void startCxfBus() throws Exception {
        bf = new SpringBusFactory();
        Bus bus = bf.createBus("META-INF/spring/cxf-client.xml");
        bf.setDefaultBus(bus);
    }

    @Test
    public void testRendportIncident() throws Exception {
        startCxfBus();
        runTest();
    }

    protected void runTest() throws Exception {

        // create input parameter
        InputReportIncident input = new InputReportIncident();
        input.setIncidentId("123");
        input.setIncidentDate("2008-08-18");
        input.setGivenName("Claus");
        input.setFamilyName("Ibsen");
        input.setSummary("Bla");
        input.setDetails("Bla bla");
        input.setEmail("davsclaus@apache.org");
        input.setPhone("0045 2962 7576");

        // create the webservice client and send the request
        Service s = Service.create(SERVICE_NAME);
        s.addPort(PORT_NAME, "http://schemas.xmlsoap.org/soap/", ADDRESS_URL);
        ReportIncidentEndpoint client = s.getPort(PORT_NAME, ReportIncidentEndpoint.class);

        OutputReportIncident out = client.reportIncident(input);

        // assert we got a OK back
        assertEquals("OK;456", out.getCode());
    }
}

http:conduit 要素の Spring 設定への追加

例5.4「SSL/TLS が有効になっている http:conduit 要素」 は、ReportIncidentEndpoint WSDL ポートの http:conduit 要素を定義する Spring 設定を示しています。http:conduit 要素は、指定の WSDL ポートを使用するクライアントプロキシーの SSL/TLS セキュリティーを有効にするように設定されます。

クライアントテストケースに Spring 設定を追加するには、src/test/resources/META-INF/spring サブディレクトリーを作成し、お気に入りのテキストエディターを使用してファイル cxf-client.xml を作成し、例5.4「SSL/TLS が有効になっている http:conduit 要素」 の内容をそのファイルに貼り付けます。

例5.4 SSL/TLS が有効になっている http:conduit 要素

<?xml version="1.0" encoding="UTF-8"?>
<beans xmlns="http://www.springframework.org/schema/beans"
       xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
       xmlns:cxf="http://camel.apache.org/schema/cxf"
       xmlns:sec="http://cxf.apache.org/configuration/security"
       xmlns:http="http://cxf.apache.org/transports/http/configuration"
       xsi:schemaLocation="
       http://www.springframework.org/schema/beans http://www.springframework.org/schema/beans/spring-beans.xsd
       http://camel.apache.org/schema/cxf http://camel.apache.org/schema/cxf/camel-cxf.xsd
       http://cxf.apache.org/configuration/security http://cxf.apache.org/schemas/configuration/security.xsd
       http://cxf.apache.org/transports/http/configuration http://cxf.apache.org/schemas/configuration/http-conf.xsd
       ">

  <http:conduit name="{http://reportincident.example.camel.apache.org}ReportIncidentEndpoint.http-conduit">
    <http:tlsClientParameters disableCNCheck="true" secureSocketProtocol="TLSv1">
      <sec:keyManagers keyPassword="ckpass">
          <sec:keyStore password="cspass" type="JKS"
          resource="certs/clientKeystore.jks" />
      </sec:keyManagers>
      <sec:trustManagers>
          <sec:keyStore password="cspass" type="JKS"
          resource="certs/clientKeystore.jks" />
      </sec:trustManagers>
      <sec:cipherSuitesFilter>
        <sec:include>.*_WITH_3DES_.*</sec:include>
        <sec:include>.*_WITH_DES_.*</sec:include>
        <sec:exclude>.*WITH_NULL.</sec:exclude>*
        <sec:exclude>.*DH_anon.</sec:exclude>*
      </sec:cipherSuitesFilter>
    </http:tlsClientParameters>
   </http:conduit>

</beans>

上記の設定に関して、以下の点に注意してください。

  • http:conduit 要素を定義するために http: および sec: namespace プレフィックスが必要です。xsi:schemaLocation 要素では、対応する http://cxf.apache.org/configuration/security および http://cxf.apache.org/transports/http/configuration namespace の場所を指定することが不可欠です。
  • http:tlsClientParameters 要素の disableCNCheck 属性は true に設定されます。つまり、クライアントが、サーバーの X.509 証明書の Common Name がサーバーのホスト名と一致するかどうかをチェックしません。詳細は、付録A 証明書の管理 を参照してください。

    重要

    実稼働デプロイメントで CN チェックを無効にすることは推奨されません

  • sec:keystore 要素では、クラスパス上の証明書を見つける resource 属性を使用して証明書の場所が指定されます。Maven がテストを実行すると、証明書が src/main/resources/certs ディレクトリーから読み取りできるように、クラスパスで src/main/resources の内容を自動的に利用できるようにします。

    注記

    また、ファイルシステム内を検索する file 属性を使用して、証明書の場所を指定するオプションもあります。ただし、resource 属性は、バンドルにパッケージ化されたアプリケーションでの使用に適しています。

  • sec:cipherSuitesFilter 要素は、.*WITH_NULL.\* および .*DH_anon.\* に一致する暗号スイートを除外するように設定されています。これらの暗号スイートは事実上不完全であり、通常の使用を目的としたものではありません

    重要

    .*WITH_NULL.\* および .*DH_anon.\* に一致する暗号を常に除外することが推奨されます。

  • secureSocketProtocol 属性は、サーバーのプロトコルと一致するように TLSv1 に設定し、SSLv3 プロトコルが使用されないようにする必要があります (POODLE セキュリティー脆弱性 (CVE-2014-3566))。

クライアントの実行

クライアントはテストケースとして定義されるため、標準の Maven テストゴールを使用してクライアントを実行できます。クライアントを実行するには、新しいコマンドウィンドウを開き、 CamelInstallDir/examples/camel-example-cxf-proxy ディレクトリーに移動し、以下の Maven コマンドを入力します。

mvn test

テストが正常に実行されると、OSGi コンソールウィンドウに次の出力が表示されます。

Incident was 123, changed to 456

Invoked real web service: id=456 by Claus Ibsen

第6章 Fuse Console のセキュア化

スタンドアロンデプロイメントで Fuse コンテナーを保護するために、次のセキュリティ機能を実装する方法については、『Managing Fuse』を参照してください。

  • 必要なプロトコルとして HTTPS を設定
  • 公開鍵を使用して応答をセキュアにする
  • SSL/TLS セキュリティーを有効にする
  • ユーザーのアクセスを制御する

デフォルトでは、Fuse Console はリモートでアクセスできません。Fuse Console にリモートでアクセスする方法の詳細は、『Managing Fuse』の「Fuse Console のアンロック」を参照してください。

第7章 Red Hat Single Sign-On との統合

Red Hat Single Sign-On (RH-SSO) オプションは JAAS と連携して、Fuse および Fuse 管理サービス (SSH、JMX、および Fuse Management Console) 内部で実行されている特定の Web クライアントアプリケーションおよびサービスに対してエンタープライズのセキュリティーを提供します。

アダプターは、Red Hat Fuse の以下のタイプのコンテナーに提供されます。

7.1. Spring Boot コンテナーのアダプター

Spring Boot コンテナーのアダプターは、以下の組み込み Web コンテナーをサポートします。

  • Undertow
  • Jetty
  • Tomcat

Spring Boot コンテナーの Red Hat Single Sign-On アダプターのインストールおよび使用に関する詳細は、Red Hat Single Sign-On『Securing Applications and Services Guide』の「Spring Boot Adapter」を参照してください。

7.2. Apache Karaf コンテナーのアダプター

Apache Karaf コンテナーのアダプターは、以下のコンポーネントを保護できます。

  • Pax Web War Extender で Fuse にデプロイされた Classic WAR アプリケーション。
  • Pax Web Whiteboard Extender で OSGi サービスとして Fuse にデプロイされたサーブレットと、標準の OSGi Enterprise HTTP Service である org.osgi.service.http.HttpService#registerServlet()` を介して登録された追加サーブレット。
  • Camel Undertow コンポーネントで実行される Apache Camel Undertow エンドポイント。
  • 個別の Undertow エンジンで実行される Apache CXF エンドポイント。
  • CXF サーブレットによって提供されるデフォルトエンジンで実行されている Apache CXF エンドポイント。
  • SSH および JMX 管理者アクセス。
  • Hawtio 管理コンソール

Apache Karaf コンテナーの Red Hat Single Sign-On アダプターのインストールおよび使用に関する詳細は、Red Hat Single Sign-On『Securing Applications and Services Guide』の「JBoss Fuse 7 Adapter」を参照してください。

7.3. JBoss EAP コンテナーのアダプター

JBoss Enterprise Application Platform (EAP) コンテナーのアダプターは、WAR のセキュリティーを提供し、URL でロールベースのセキュリティー制約を定義できます。

JBoss EAP コンテナーの Red Hat Single Sign-On アダプターのインストールおよび使用に関する詳細は、Red Hat Single Sign-On『Securing Applications and Services Guide』の「JBoss EAP Adapter」を参照してください。

第8章 LDAP 認証チュートリアル

概要

このチュートリアルでは、X.500 ディレクトリーサーバーを設定し、LDAP 認証を使用するように OSGi コンテナーを設定する方法を説明します。

8.1. チュートリアルの概要

ゴール

このチュートリアルでは、以下を行います。

  • 389 Directory Server のインストール
  • LDAP サーバーへのユーザーエントリーの追加
  • セキュリティーロールを管理するグループの追加
  • LDAP 認証を使用するように Fuse を設定
  • 承認にロールを使用するように Fuse を設定
  • LDAP サーバーへの SSL/TLS 接続の設定

8.2. Directory Server およびコンソールの設定

本チュートリアルでは、Fedora 389 Directory Server プロジェクトから X.500 ディレクトリーサーバーと管理コンソールをインストールする方法について説明します。389 Directory Server インスタンスにすでにアクセスできる場合は、389 Directory Server のインストール手順を省略し、代わりに 389 Management Console をインストールできます。

前提条件

Red Hat Enterprise Linux プラットフォームにインストールする場合は、最初に Extra Packages for Enterprise Linux (EPEL) をインストールする必要があります。fedoraproject.org サイトの RHEL/Cent OS/ EPEL ( RHEL 6, RHEL 7, Cent OS 6, Cent OSý7) にあるインストールノートを参照してください。

389 Directory Server のインストール

既存の 389 Directory Server インスタンスにアクセスできない場合は、以下のように 389 Directory Server をローカルマシンにインストールできます。

  1. Red Hat Enterprise Linux および Fedora プラットフォームでは、標準の dnf パッケージ管理ユーティリティーを使用して 389 Directory Server をインストールします。コマンドプロンプトに以下のコマンドを入力します (マシンの管理者権限が必要です)。

    sudo dnf install 389-ds
    注記

    必要な 389-ds および 389-console RPM パッケージは、Fedora、RHEL6+EPEL、および CentOS7+EPEL のプラットフォームで利用できます。執筆時点では、389-console パッケージは RHEL 7 では利用できません。

  2. 389 ディレクトリーサーバーパッケージをインストールした後、以下のコマンドを実行してディレクトリーサーバーを設定します。

    sudo setup-ds-admin.pl

    このスクリプトは対話型で、389 Directory Server の基本設定を指定するように求められます。スクリプトが完了すると、バックグラウンドで 389 Directory Server が自動的に起動します。

  3. 389 Directory Server のインストール方法の詳細は、Download ページを参照してください。

389 Management Console のインストール

389 Directory Server インスタンスにアクセスできる場合は、389 Management Console のみをインストールする必要があります。これにより、リモートでサーバーにログインし、管理できます。以下のように 389 Management Console をインストールできます。

  • Red Hat Enterprise Linux および Fedora プラットフォームの場合 - 標準の dnf パッケージ管理ユーティリティーを使用して、389 Management Console をインストールします。コマンドプロンプトに以下のコマンドを入力します (マシンの管理者権限が必要です)。

    sudo dnf install 389-console
  • Windows プラットフォームの場合 - fedoraproject.orgWindows Console のダウンロード手順を参照してください。

コンソールのサーバーへの接続

389 Directory Server Console を LDAP サーバーに接続するには、以下を行います。

  1. 以下のコマンドを入力して、389 Management Console を起動します。

    389-console
  2. ログインダイアログが表示されます。User ID および Password フィールドに LDAP ログインクレデンシャルを入力し、Administration URL フィールドのホスト名をカスタマイズして 389 管理サーバーインスタンスに接続します (ポート 9830 は 389 管理サーバーインスタンスのデフォルトポートです)。

    LDAP Console Login
  3. 389 Management Console ウィンドウが表示されます。Servers and Applications タブを選択します。
  4. 左側のペインで、Directory Server アイコンを見つけます。

    LDAP Console Open
  5. 左側のペインで Directory Server アイコンを選択し、Open をクリックして 389 Directory Server Console を開きます。
  6. 389 Directory Server Console で、Directory タブをクリックして Directory Information Tree (DIT) を表示します。
  7. ルートノード YourDomain (通常はホスト名にちなんで命名され、次のスクリーンショットの localdomain のように表示) を展開して、DIT を表示します。

    LDAP ServerConsole DIT

8.3. ディレクトリーサーバーへのユーザーエントリーの追加

OSGi コンテナーで LDAP 認証を使用するための基本的な前提条件は、X.500 ディレクトリーサーバーが実行し、ユーザーエントリーのコレクションで設定することです。多くのユースケースでは、ユーザーロールを管理するために複数のグループを設定する必要もあります。

ユーザーエントリー追加の代替

LDAP サーバーにユーザーエントリーおよびグループがすでに定義されている場合は、新規エントリーを作成する代わりに、LDAPLoginModule 設定の roles.mapping プロパティーを使用して既存の LDAP グループを JAAS ロールにマッピングした方が好ましい場合があります。詳細は、「JAAS LDAP ログインモジュール」 を参照してください。

ゴール

本チュートリアルでは、以下を行います。

ユーザーエントリーの追加

ディレクトリーサーバーにユーザーエントリーを追加するには、以下の手順を実行します。

  1. LDAP サーバーおよびコンソールが稼働していることを確認します。「Directory Server およびコンソールの設定」 を参照してください。
  2. Directory Server Console で、Directory タブをクリックし、YourDomain ノード下で People ノードを見つけます (以下のスクリーンショットでは YourDomainlocaldomain として表示されてます)。

    directory information tree in the LDAP browser
  3. People ノードを右クリックし、コンテキストメニューから menu:[ > New > > User > ] と選択して Create New User ダイアログを開きます。
  4. Create New User ダイアログの左側のペインで User タブを選択します。
  5. 以下のように User タブのフィールドを入力します。

    1. First Name フィールドを John に設定します。
    2. Last Name フィールドを Doe に設定します。
    3. User ID フィールドを jdoe に設定します。
    4. Password フィールドにパスワード secret を入力します。
    5. Confirm Password フィールドにパスワード secret を入力します。

      Filling the fields of the User tab in the Create New User dialog
  6. OK をクリックします。
  7. Step 3 から Step 6 に従って、ユーザー Jane Doe を追加します。

    Step 5.e で、新規ユーザーの User IDjanedoe を使用し、パスワードフィールドにはパスワード secret を使用します。

  8. Step 3 から Step 6 に従って、ユーザー Camel Rider を追加します。

    Step 5.e で、新規ユーザーの User IDcrider を使用し、パスワードフィールドにはパスワード secret を使用します。

ロールのグループの追加

ロールを定義するグループを追加するには、以下を実行します。

  1. Directory Server ConsoleDirectory タブで、YourDomain ノード下の Groups ノードを見つけます。
  2. Groups ノードを右クリックし、コンテキストメニューから menu:[ > New > > Group > ] と選択して Create New Group ダイアログを開きます。
  3. Create New Group ダイアログの左側のペインで General タブを選択します。
  4. 以下のように General タブのフィールドを入力します。

    1. Group Name フィールドを admin に設定します。
    2. 必要に応じて、Description フィールドに説明を入力します。

      Filling the fields of the General tab in the Create New Group dialog
  5. Create New Group ダイアログの左側のペインで Members タブを選択します。

    Filling the fields of the Members tab in the Create New Group dialog
  6. Add をクリックして Search users and groups ダイアログを開きます。
  7. Search フィールドで、ドロップダウンメニューから Users を選択し、Search ボタンをクリックします。

    LDAP SearchUsers
  8. 表示されているユーザーのリストから、John Doe を選択します。
  9. OK をクリックして Search users and groups ダイアログを閉じます。
  10. OK をクリックして Create New Group ダイアログを閉じます。
  11. Step 2 から Step 10 に従って、manager ロールを追加します。

    Step 4Group Name フィールドに manager を入力します。

    Step 8 で、Jane Doe を選択します。

  12. Step 2 から Step 10 に従って、viewer ロールを追加します。

    Step 4Group Name フィールドに viewer を入力します。

    Step 8 で、Camel Rider を選択します。

  13. Step 2 から Step 10 に従って、ssh ロールを追加します。

    Step 4Group Name フィールドに ssh を入力します。

    Step 8 で、John DoeJane Doe、および Camel Riderすべてのユーザーを選択します。

8.4. OSGi コンテナーでの LDAP 認証の有効化

本セクションでは、OSGi コンテナーで LDAP レルムを設定する方法を説明します。新しいレルムはデフォルトの karaf レルムを上書きするため、コンテナーは X.500 ディレクトリーサーバーに保存されているユーザーエントリーを基にしてクレデンシャルを認証します。

参考資料

LDAP 認証については、より詳細な以下のドキュメントを参照してください。

スタンドアロン OSGi コンテナーの手順

スタンドアロンの OSGi コンテナーで LDAP 認証を有効にするには、以下を実行します。

  1. X.500 ディレクトリーサーバーが稼働していることを確認します。
  2. ターミナルウインドウに以下のコマンドを入力して、Karaf コンテナーを起動します。

    ./bin/fuse
  3. ldap-module.xml という名前のファイルを作成します。
  4. 例8.1「スタンドアロンの JAAS レルム」ldap-module.xml にコピーします。

    例8.1 スタンドアロンの JAAS レルム

    <?xml version="2.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="karaf" rank="200">
        <jaas:module className="org.apache.karaf.jaas.modules.ldap.LDAPLoginModule"
                     flags="required">
          initialContextFactory=com.sun.jndi.ldap.LdapCtxFactory
          connection.url=ldap://localhost:389
          connection.username=cn=Directory Manager
          connection.password=DIRECTORY_MANAGER_PASSWORD
          connection.protocol=
          user.base.dn=ou=People,dc=localdomain
          user.filter=(&amp;(objectClass=inetOrgPerson)(uid=%u))
          user.search.subtree=true
          role.base.dn=ou=Groups,dc=localdomain
          role.name.attribute=cn
          role.filter=(uniquemember=%fqdn)
          role.search.subtree=true
          authentication=simple
        </jaas:module>
      </jaas:config>
    </blueprint>

    ldap-module.xml ファイルで以下の設定をカスタマイズする必要があります。

    connection.url
    この URL を、ディレクトリーサーバーインスタンスの実際の場所に設定します。通常、この URL の形式は ldap://Hostname:Port です。たとえば、389 Directory Server のデフォルトポートは IP ポート 389 です。
    connection.username
    ディレクトリーサーバーへの接続の認証に使用されるユーザー名を指定します。389 Directory Server の場合、デフォルトは通常 cn=Directory Manager です。
    connection.password
    ディレクトリーサーバーに接続するためのクレデンシャルのパスワード部分を指定します。
    authentication

    認証プロトコルには、以下のいずれかの方法を指定できます。

    • simple の場合、ユーザークレデンシャルが提供され、connection.username オプションおよび connection.password オプションを設定する義務があることを意味します。
    • none の場合、認証が行われないことを意味します。この場合、connection.username および connection.password オプションを設定しないでください。

      このログインモジュールは、karaf という名前の JAAS レルムを作成します。これは、Fuse によって使用されるデフォルトの JAAS レルムと同じ名前です。0 より大きい rank 属性の値でこのレルムを再定義すると、ランク 0 を持つ標準 karaf レルムがオーバーライドされます。

      LDAP を使用するよう Fuse を設定する方法の詳細は、「JAAS LDAP ログインモジュール」 を参照してください。

      重要

      上記の JAAS プロパティーを設定する場合は、プロパティー値を二重引用符で囲まないでください。

  5. 新しい LDAP モジュールをデプロイするには、ldap-module.xml を Karaf コンテナーの deploy/ ディレクトリー (ホットデプロイ) にコピーします。

    LDAP モジュールは自動的にアクティベートされます。

    注記

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

LDAP 認証のテスト

以下のように Karaf client ユーティリティーを使用して実行中のコンテナーに接続し、新しい LDAP レルムをテストします。

  1. 新しいコマンドプロンプトを開きます。
  2. Karaf InstallDir/bin ディレクトリーに移動します。
  3. 以下のコマンドを入力し、ID jdoe を使用して実行中のコンテナーインスタンスにログインします。

    ./client -u jdoe -p secret

    コンテナーのリモートコンソールに正常にログインする必要があります。コマンドコンソールで、jaas: と入力した後に [Tab] キーを押します (コンテンツ補完を使用)。

    jdoe@root()> jaas:
    Display all 31 possibilities? (31 lines)?
    jaas:cancel
    jaas:group-add
    ...
    jaas:whoami

    jdoe がすべての jaas コマンド (admin と一致) にアクセスできることが確認できるはずです。

  4. logout コマンドを入力して、リモートコンソールからログアウトします。
  5. 以下のコマンドを入力し、ID janedoe を使用して実行中のコンテナーインスタンスにログインします。

    ./client -u janedoe -p secret

    コンテナーのリモートコンソールに正常にログインする必要があります。コマンドコンソールで、jaas: と入力した後に [Tab] キーを押します (コンテンツ補完を使用)。

    janedoe@root()> jaas:
    Display all 25 possibilities? (25 lines)?
    jaas:cancel
    jaas:group-add
    ...
    jaas:users

    janedoe がほぼすべての jaas コマンド (manager と一致) にアクセスできることが確認できるはずです。

  6. logout コマンドを入力して、リモートコンソールからログアウトします。
  7. 以下のコマンドを入力し、ID crider を使用して実行中のコンテナーインスタンスにログインします。

    ./client -u crider -p secret

    コンテナーのリモートコンソールに正常にログインする必要があります。コマンドコンソールで、jaas: と入力した後に [Tab] キーを押します (コンテンツ補完を使用)。

    crider@root()> jaas:
    jaas:manage
    jaas:realm-list
    jaas:realm-manage
    jaas:realms
    jaas:user-list
    jaas:users

    crider は 5 つの jaas コマンド (viewer と一致) のみにアクセスできることが確認できるはずです。

  8. logout コマンドを入力して、リモートコンソールからログアウトします。

トラブルシューティング

LDAP 接続のテスト中に問題が発生した場合は、ログレベルを DEBUG に引き上げ、LDAP サーバーへの接続で何が起こっているかを詳細にトレースします。

以下の手順を実行します。

  1. Karaf コンソールから以下のコマンドを入力し、ログレベルを DEBUG に引き上げます。

    log:set DEBUG
  2. Karaf ログインをリアルタイムで確認します。

    log:tail

    ログリストからエスケープするには、Ctrl-C を入力します。

付録A 証明書の管理

概要

TLS 認証では、X.509 証明書を使用します。これは、アプリケーションオブジェクトを認証するための一般的かつ安全で信頼性の高い方法です。Red Hat Fuse アプリケーションを識別する X.509 証明書を作成することができます。

A.1. X.509 証明書とは?

証明書の役割

X.509 証明書は、名前を公開鍵の値にバインドします。証明書の役割は、公開鍵を X.509 証明書に含まれる ID に関連付けることです。

公開鍵の整合性

安全なアプリケーションの認証は、アプリケーションの証明書における公開鍵の値の整合性に依存します。偽のユーザーが公開鍵を独自の公開鍵に置き換える場合、本物のアプリケーションになりすまして、安全なデータにアクセスできるようになります。

この種の攻撃を防ぐには、すべての証明書が証明機関 (CA) によって署名されている必要があります。CA は、証明書の公開鍵の値の整合性を確認する信頼できるノードです。

デジタル署名

CA は、証明書に デジタル署名 を追加することで証明書に署名します。デジタル署名は、CA の秘密鍵でエンコードされたメッセージです。CA の証明書を配布することにより、アプリケーションは CA の公開鍵を使用できるようになります。アプリケーションは、CA のデジタル署名を CA の公開鍵でデコードすることにより、証明書が正しく署名されていることを確認します。

警告

提供されるデモ証明書は自己署名証明書です。これらの証明書は、誰でも秘密鍵にアクセスできるため、安全ではありません。システムを保護するには、信頼できる CA によって署名された新しい証明書を作成する必要があります。

X.509 証明書の内容

X.509 証明書には、証明書のサブジェクトと証明書の発行元 (証明書を発行した CA) に関する情報が含まれます。証明書は Abstract Syntax Notation One (ASN.1) でエンコードされています。これは、ネットワーク上で送受信できるメッセージを説明する標準構文です。

証明書の役割は、ID を公開鍵の値に関連付けることです。以下は、証明書の詳細になります。

  • 証明書の所有者を識別する サブジェクト識別名 (DN)
  • サブジェクトに関連付けられた 公開鍵
  • X.509 バージョン情報
  • 証明書を一意に識別する シリアル番号
  • 証明書を発行した CA を識別する 発行元 DN
  • 発行元のデジタル署名
  • 証明書の署名に使用するアルゴリズムの情報
  • 複数のオプションの X.509 v.3 エクステンション: たとえば、CA 証明書とエンドエンティティー証明書を区別するエクステンションが存在します。

識別名

DN は、セキュリティーのコンテキストでよく使用される汎用の X.500 識別子です。

DN の詳細は 付録B ASN.1 および識別名 を参照してください。

A.2. 認証局

A.2.1. 認証局の概要

CA は、証明書を生成および管理するための一連のツールと、生成されたすべての証明書を含むデータベースで構成されます。システムをセットアップする際は、要件に対して十分に安全かつ適切な CA を選択することが重要です。

使用可能な CA には 2 つのタイプがあります。

  • 商用の CA は、多くのシステムに対して証明書に署名する企業です。
  • プライベート CA は、お使いのシステムの証明書のみに署名するためにセットアップして使用する信頼できるノードです。

A.2.2. 商業認証局

証明書の署名

複数の商用 CA が利用可能です。商用 CA を使用して証明書に署名するメカニズムは、選択する CA によって異なります。

商用 CA の利点

多くの場合、商用 CA の利点は多数の人から信頼されていることです。アプリケーションが組織外のシステムで利用できるように設計されている場合は、商用 CA を使用して証明書に署名します。アプリケーションが内部ネットワーク内での使用を目的とする場合は、プライベート CA が適切とされます。

CA の選択基準

商用 CA を選択する前に、以下の基準を考慮してください。

  • 商用 CA の証明書署名ポリシーとは何ですか?
  • アプリケーションは、内部ネットワークでのみ使用できるように設計されていますか?
  • 商用 CA にサブスクライブするコストと比較した場合、プライベート CA のセットアップにかかる潜在的なコストはどれくらいですか?

A.2.3. プライベート認証局

CA ソフトウェアパッケージの選択

システムの証明書の署名に対して責任を持つ場合は、プライベート CA を設定してください。プライベート CA を設定するには、証明書の作成および署名を行うユーティリティーを提供するソフトウェアパッケージへのアクセスが必要です。このタイプのパッケージはいくつか利用可能です。

OpenSSL ソフトウェアパッケージ

プライベート CA を設定できるソフトウェアパッケージの 1 つに、OpenSSL (http://www.openssl.org) があります。OpenSSL パッケージには、証明書を生成および署名する基本的なコマンドラインユーティリティーが含まれています。OpenSSL コマンドラインユーティリティーの完全なドキュメントは、http://www.openssl.org/docs から入手できます。

OpenSSL を使用したプライベート CA の設定

プライベート CA を設定するには、「独自の証明書の作成」 の手順を参照してください。

プライベート認証局のホストの選択

ホストの選択は、プライベート CA のセットアップにおける重要なステップです。CA ホストに関連付けられたセキュリティーのレベルは、CA が署名した証明書に関連付けられた信頼レベルを決定します。

Red Hat Fuse アプリケーションの開発およびテストに使用する CA を設定する場合は、アプリケーション開発者がアクセスできる任意のホストを使用してください。ただし、CA 証明書と秘密鍵を作成する場合は、セキュリティーが重要なアプリケーションが実行されているホストで CA 秘密鍵を使用可能にしないでください。

セキュリティー上の予防措置

デプロイするアプリケーションの証明書に署名するように CA を設定する場合は、可能な限り CA ホストのセキュリティーを保護します。たとえば、CA のセキュリティーを保護するには、以下の予防措置をとります。

  • CA をネットワークに接続しないでください。
  • CA へのすべてのアクセスを、信頼できるユーザーの限られたセットに制限します。
  • RF シールドを使用して、CA を無線周波数の監視から保護します。

A.3. 証明書チェーン

証明書チェーン

証明書チェーン は証明書のシーケンスで、チェーンの各証明書が後続の証明書によって署名されます。

図A.1「Depth 2 の証明書チェーン」 は、簡単な証明書チェーンの例を示しています。

図A.1 Depth 2 の証明書チェーン

a certificate chain of depth 2 has only one CA signature

自己署名証明書

通常、チェーンの最後の証明書は 自己署名証明書 (自分自身で署名する証明書) です。

信頼のチェーン

証明書チェーンの目的は、ピア証明書から信頼できる CA 証明書に信頼チェーンを確立することです。CA は、ピア証明書に署名することにより、その ID を保証します。CA が信頼するものである場合は (ルート証明書ディレクトリーに CA 証明書のコピーが存在することで示される)、署名されたピア証明書も信頼できることを意味します。

複数の CA が署名する証明書

CA 証明書は別の CA によって署名されることができます。たとえば、アプリケーション証明書は、Progress Software の財務部門の CA によって署名され、Progress Software は自己署名された商用 CA によって署名されます。

図A.2「Depth 3 の証明書チェーン」 は、この証明書チェーンの概要を示しています。

図A.2 Depth 3 の証明書チェーン

a certificate chain of depth 3 has two CA signatures

信頼できる CA

アプリケーションは、署名チェーン内の CA 証明書の少なくとも 1 つを信頼していれば、ピア証明書を受け入れることができます。

A.4. HTTPS 証明書における特別な要件

概要

HTTPS仕様では、HTTPS クライアントがサーバー ID を検証できなければならないことが義務付けられています。これは、X.509 証明書の生成方法に影響を及ぼす可能性があります。サーバー ID を検証するメカニズムは、クライアントのタイプによって異なります。クライアントによっては、特定の信頼できる CA によって署名されたサーバー証明書のみを受け入れることで、サーバー ID を検証する場合があります。さらに、クライアントはサーバー証明書の内容を検査し、特定の制約を満たす証明書のみを受け入れることができます。

アプリケーション固有のメカニズムがない場合、HTTPS 仕様はサーバー ID を検証するために HTTPS URL の整合性チェック と呼ばれる一般的なメカニズムを定義します。これは、Web ブラウザーが使用する標準のメカニズムです。

HTTPS URL 整合性チェック

URL 整合性チェックの基本的な概念は、サーバー証明書の ID がサーバーのホスト名と一致する必要があることです。この整合性チェックは、HTTPS の X.509 証明書を生成する方法に重要な影響を及ぼします。証明書 ID (通常は証明書のサブジェクト DN の共通名) は、HTTPS サーバーがデプロイされるホスト名と一致する必要があります

URL 整合性チェックは、中間者 攻撃を阻止するように設計されています。

リファレンス

HTTPS URL 整合性チェックは、インターネット技術標準化委員会 (IETF) がhttp://www.ietf.org/rfc/rfc2818.txt に公開している RFC 2818 によって指定されています。

証明書 ID の指定方法

URL 整合性チェックで使用される証明書 ID は、以下のいずれかの方法で指定できます。

commonName の使用

(URL 整合性チェックの目的で) 証明書 ID を指定する通常の方法は、証明書のサブジェクト DN の共通名 (CN) を使用することです。

たとえば、サーバーが以下の URL でセキュアな TLS 接続に対応している場合、

https://www.redhat.com/secure

対応するサーバー証明書には以下のサブジェクト DN があります。

C=IE,ST=Co. Dublin,L=Dublin,O=RedHat,
OU=System,CN=www.redhat.com

ここで、CN はホスト名 www.redhat.com に設定されています。

新しい証明書でサブジェクト DN を設定する方法の詳細は、「独自の証明書の作成」 を参照してください。

subjectAltName の使用 (マルチホームホスト)

証明書 ID にサブジェクト DN の共通名 (CN) を使用すると、一度に 1 つの ホスト名しか指定できないという欠点があります。ただし、マルチホームホストに証明書を展開する場合は、証明書を 任意 のマルチホームホスト名で使用できるようにすることが実用的である場合があります。この場合、複数の代替 ID を使用して証明書を定義する必要があります。これは、subjectAltName 証明書エクステンションを使用する場合に限り可能です。

たとえば、以下のホスト名のいずれかへの接続をサポートするマルチホームホストがある場合は、以下のようになります。

www.redhat.com
www.jboss.org

次に、これらの DNS ホスト名の両方を明示的に一覧表示する subjectAltName を定義できます。openssl ユーティリティーを使用して証明書を生成する場合は、以下のように openssl.cnf 設定ファイルに関連する行を編集し、subjectAltName エクステンションの値を指定します。

subjectAltName=DNS:www.redhat.com,DNS:www.jboss.org

ここで、HTTPS プロトコルは、subjectAltName に一覧表示されている DNS ホスト名のいずれかに対してサーバーホスト名が一致します (subjectAltName は共通名よりも優先されます)。

HTTPS プロトコルは、ホスト名のワイルドカード文字 (\*) もサポートしています。たとえば、以下のように subjectAltName を定義できます。

subjectAltName=DNS:*.jboss.org

この証明書 ID は、ドメイン jboss.org 内の任意の 3 つのコンポーネントのホスト名と一致します。

警告

ドメイン名にワイルドカード文字を 使用しないでください (ドメイン名の前にドット . の区切り文字を入力し忘れて、誤って使用しないように注意する必要があります)。たとえば、*jboss.org を指定した場合、証明書は jboss 文字で終わる *任意* のドメインで使用できます。

A.5. 独自の証明書の作成

概要

本章では、独自のプライベート認証局 (CA) をセットアップする手法および手順を説明し、この CA を使用して独自の証明書を生成および署名する方法を説明します。

警告

独自の証明書を作成および管理するには、セキュリティーの専門知識が必要です。本章で説明する手順は、デモ環境やテスト環境用に独自の証明書を生成する場合に便利ですが、実稼働環境でこれらの証明書を使用することは推奨されません

A.5.1. OpenSSL ユーティリティーのインストール

RHEL および Fedora プラットフォームへの OpenSSL のインストール

Red Hat Enterprise Linux( RHEL) 5 および 6 プラットフォームと、Fedora プラットフォームでは、RPM パッケージとして利用できます。OpenSSL をインストールするには、以下のコマンドを入力します (管理者権限で実行します)。

yum install openssl

ソースコードのディストリビューション

OpenSSL のソースディストリビューションは http://www.openssl.org/docs から入手できます。OpenSSL プロジェクトは、ソースコードのディストリビューションのみを提供します。OpenSSL Web サイトからは OpenSSL ユーティリティーのバイナリーインストールをダウンロードできません。

A.5.2. プライベート認証局の設定

概要

プライベート CA を使用する場合、アプリケーションが使用するために独自の証明書を生成する必要があります。OpenSSL プロジェクトは、プライベート CA の設定、署名済み証明書の作成、および CA の Java キーストアへの追加を行うための無料コマンドラインユーティリティーを提供します。

警告

実稼働環境でプライベート CA を設定するには、高いレベルの専門知識が必要で、外部の脅威から証明書ストアを保護するために特別な注意が必要です。

プライベート認証局の設定手順

独自のプライベート認証局を設定するには、以下を実行します。

  1. 以下のように CA のディレクトリー構造を作成します。

    X509CA/demoCA
    X509CA/demoCA/private
    X509CA/demoCA/certs
    X509CA/demoCA/newcerts
    X509CA/demoCA/crl
  2. テキストエディターを使用して、X509CA/openssl.cfg ファイルを作成し、以下の内容をこのファイルに追加します。

    例A.1 OpenSSL の設定

    #
    # SSLeay example configuration file.
    # This is mostly being used for generation of certificate requests.
    #
    
    RANDFILE            = ./.rnd
    
    ####################################################################
    [ req ]
    default_bits        = 2048
    default_keyfile     = keySS.pem
    distinguished_name  = req_distinguished_name
    encrypt_rsa_key     = yes
    default_md          = sha1
    
    [ req_distinguished_name ]
    countryName         = Country Name (2 letter code)
    
    organizationName    = Organization Name (eg, company)
    
    commonName          = Common Name (eg, YOUR name)
    
    ####################################################################
    [ ca ]
    default_ca         = CA_default        # The default ca section
    
    ####################################################################
    [ CA_default ]
    
    dir                = ./demoCA              # Where everything is kept
    certs              = $dir/certs            # Where the issued certs are kept
    crl_dir            = $dir/crl              # Where the issued crl are kept
    database           = $dir/index.txt        # database index file.
    #unique_subject    = no                    # Set to 'no' to allow creation of
                                               # several certificates with same subject.
    new_certs_dir      = $dir/newcerts         # default place for new certs.
    
    certificate        = $dir/cacert.pem       # The CA certificate
    serial             = $dir/serial           # The current serial number
    crl                = $dir/crl.pem          # The current CRL
    private_key        = $dir/private/cakey.pem# The private key
    RANDFILE           = $dir/private/.rand    # private random number file
    
    name_opt           = ca_default            # Subject Name options
    cert_opt           = ca_default            # Certificate field options
    
    default_days       = 365                   # how long to certify for
    default_crl_days   = 30                    # how long before next CRL
    default_md         = md5                   # which md to use.
    preserve           = no                    # keep passed DN ordering
    
    policy             = policy_anything
    
    [ policy_anything ]
    countryName            = optional
    stateOrProvinceName    = optional
    localityName           = optional
    organizationName       = optional
    organizationalUnitName = optional
    commonName             = supplied
    emailAddress           = optional
    重要

    前述の openssl.cfg 設定ファイルは、デモンストレーションとしてのみ提供されます。本番環境では、セキュリティーに関する高度な専門知識を持つエンジニアがこの設定ファイルを慎重に検討し、進化するセキュリティーの脅威から保護するために積極的に維持する必要があります。

  3. demoCA/serial ファイルを初期化します。このファイルには、初期のコンテンツ 01 が必要です。以下のコマンドを入力します。

    echo 01 > demoCA/serial
  4. demoCA/index.txt を初期化します。最初は空である必要があります。以下のコマンドを入力します。

    touch demoCA/index.txt
  5. 以下のコマンドを使用して、新しい自己署名 CA 証明書と秘密鍵を作成します。

    openssl req -x509 -new -config openssl.cfg -days 365 -out demoCA/cacert.pem -keyout demoCA/private/cakey.pem

    例A.2「CA 証明書の作成」 に示されるように、CA 秘密鍵のパスフレーズおよび CA 識別名の詳細を入力するよう求められます。

    例A.2 CA 証明書の作成

    Generating a 2048 bit RSA private key
    ...........................................................................+++
    .................+++
    writing new private key to 'demoCA/private/cakey.pem'
    Enter PEM pass phrase:
    Verifying - Enter PEM pass phrase:
    -----
    You are about to be asked to enter information that will be incorporated
    into your certificate request.
    What you are about to enter is what is called a Distinguished Name or a DN.
    There are quite a few fields but you can leave some blank
    For some fields there will be a default value,
    If you enter '.', the field will be left blank.
    -----
    Country Name (2 letter code) []:DE
    Organization Name (eg, company) []:Red Hat
    Common Name (eg, YOUR name) []:Scooby Doo
    注記

    CA のセキュリティは、この手順で使用される秘密鍵ファイルと秘密鍵パスフレーズのセキュリティーによって異なります。

    CA 証明書と秘密鍵 (cacert.pem および cakey.pem) のファイル名と場所が、openssl.cfg で指定した値と同じであることを確認してください。

A.5.3. CA トラストストアファイルの作成

概要

通常、サーバーのアイデンティティーを確認するために、SSL/TLS 接続のクライアント側でトラストストアファイルが必要です。トラストストアファイルは、デジタル署名のチェックにも使用できます (たとえば、トラストストアファイルの信用できる証明書の 1 つに対応する秘密鍵を使用して署名されたことをチェックするなど)。

CA トラストストアの作成手順

1 つ以上 CA 証明書の 1 つをトラストストアファイルに追加するには、以下を実行します。

  1. デプロイする信頼できる CA 証明書のコレクションをアセンブルします。

    信頼できる CA 証明書は、パブリック CA またはプライベート CA から取得できます。信頼できる CA 証明書は、Java keystore ユーティリティー (例: PEM 形式) と互換性のある任意の形式にすることができます。必要なのは証明書だけです。秘密鍵とパスワードは必要ありません

  2. keytool -import コマンドを使用して、CA 証明書をトラストストアに追加します。

    以下のコマンドを入力して、PEM 形式の CA 証明書 cacert.pem を JKS トラストストアに追加します。

    keytool -import -file cacert.pem -alias CAAlias -keystore truststore.ts -storepass StorePass

    truststore.ts は、CA 証明書が含まれるキーストアファイルです。このファイルが存在しない場合は、keytool コマンドにより作成されます。CAAlias は、インポートされた CA 証明書の便利な識別子です。StorePass はキーストアファイルへのアクセスに必要なパスワードです。

  3. 直前の手順を繰り返し、すべての CA 証明書をトラストストアに追加します。

A.5.4. 新しい証明書の生成および署名

概要

証明書を実際に活用するには、証明書の真正性を証明する CA によって署名されなければなりません。これにより、単一の CA 証明書を使用して大量の証明書を検証できるため、証明書のスケーラブルなソリューションが容易になります。

新しい証明書の生成および署名手順

独自のプライベート CA を使用して新しい証明書を生成および署名するには、以下の手順を実行します。

  1. 以下のように、keytool -genkeypair コマンドを使用して、証明書と秘密鍵のペアを生成します。

    keytool -genkeypair -keyalg RSA -dname "CN=Alice, OU=Engineering, O=Red Hat, ST=Dublin, C=IE" -validity 365 -alias alice -keypass KeyPass -keystore alice.ks -storepass StorePass

    指定のキーストア alice.ks はコマンドを実行する前に存在していなかったため、暗黙的に新しいキーストアが作成され、パスワードが StorePass に設定されます。

    -dname および -validity フラグは、新たに作成された X.509 証明書の内容を定義します。

    注記

    証明書の識別名 (-dname パラメーターを使用した) を指定する場合は、openssl.cfg ファイルで指定されたポリシー制約を必ず守る必要があります。これらのポリシー制約に従わないと、CA を使用して証明書に署名できません (次の手順で)。

    注記

    -keyalg RSA オプション (または同様の強度の鍵アルゴリズム) を使用してキーペアを生成することが不可欠です。デフォルトのキーアルゴリズムでは、DSA 暗号化と SHA-1 署名の組み合わせが使用されます。しかし、SHA-1 アルゴリズムは十分に安全であるとはみなされなくなり、最新の Web ブラウザは SHA-1 を使用して署名された証明書を拒否します。RSA 鍵アルゴリズムを選択すると、keytool ユーティリティーは代わりに SHA-2 アルゴリズムを使用します。

  2. keystore -certreq コマンドを使用して、証明書署名要求を作成します。

    以下のように、alice.ks 証明書の新規の証明書署名要求を作成し、alice_csr.pem ファイルにエクスポートします。

    keytool -certreq -alias alice -file alice_csr.pem -keypass KeyPass -keystore alice.ks -storepass StorePass
  3. openssl ca コマンドを使用して CSR に署名します。

    以下のように、プライベート CA を使用して Alice 証明書の CSR に署名します。

    openssl ca -config openssl.cfg -days 365 -in alice_csr.pem -out alice_signed.pem

    CA の作成時 (「プライベート認証局の設定手順」) に使用した CA 秘密鍵のパスフレーズを入力するよう求められます。

    openssl ca コマンドについての詳細は、http://www.openssl.org/docs/apps/ca.html# を参照してください。

  4. -outform オプションが PEM に設定された openssl x509 コマンドを使用して、署名付き証明書を PEM専用形式に変換します。以下のコマンドを入力します。

    openssl x509 -in alice_signed.pem -out alice_signed.pem -outform PEM
  5. CA 証明書ファイルと、変換された署名済み証明書ファイルを連結して、証明書チェーンを形成します。たとえば、Linux および UNIX プラットフォームでは、以下のように CA 証明書ファイルと署名済み Alice 証明書 alice_signed.pem を連結できます。

    cat demoCA/cacert.pem alice_signed.pem > alice.chain
  6. keytool -import コマンドを使用して、新しい証明書の完全な証明書チェーンを Java キーストアにインポートします。以下のコマンドを入力します。

    keytool -import -file alice.chain -keypass KeyPass -keystore alice.ks -storepass StorePass

付録B ASN.1 および識別名

概要

OSI Abstract Syntax Notation One (ASN.1) および X.500 Distinguished Names は、X.509 証明書および LDAP ディレクトリーを定義するセキュリティー標準で重要な役割を果たします。

B.1. ASN.1

概要

Abstract Syntax Notation One (ASN.1) は、特定のマシンハードウェアやプログラミング言語に依存しないデータ型と構造を定義する方法を提供するために、1980 年代初頭に OSI 標準機関によって定義されました。多くの点で、ASN.1 は、プラットフォームに依存しないデータ型の定義に関係する OMG の IDL や WSDL などの、最新のインターフェース定義言語の先駆けと見なすことができます。

ASN.1 は標準の定義 (SNMP、X.509、LDAP など) で広く使用されているため、重要です。特に、ASN.1 はセキュリティー標準の分野で広く普及しています。X.509 証明書および識別名の正式な定義は、ASN.1 構文を使用して説明されています。これらのセキュリティー標準を使用するために ASN.1 構文の詳細な知識は必要ありませんが、ASN.1 はほとんどのセキュリティー関連データ型の基本的な定義に使用される点に留意する必要があります。

BER

OSI の Basic Encoding Rules (BER) は、ASN.1 データ型を octets (バイナリー表現) のシーケンスに変換する方法を定義します。したがって、ASN.1 に対する BER の役割は、OMGIDL に対する GIOP の役割と同じになります。

DER

OSI の識別されたエンコーディングルール (DER) は、BER に特化したものです。DER は BER に加えて、エンコードが一意となるように追加のルールで構成されます (BER エンコーディングは一意ではありません)。

参考資料

ASN.1 の詳細については、以下の標準ドキュメントを参照してください。

  • ASN.1 は X.208 で定義されています。
  • BER は X.209 で定義されています。

B.2. 識別名

概要

従来から、識別名 (DN) は、X.500 ディレクトリー構造のプライマリーキーとして定義されています。ただし、DNは、他の多くのコンテキストで汎用識別子として使用されるようになりました。Apache CXF では、DN は以下のコンテキストで発生します。

  • X.509 証明書: たとえば、証明書内の DN の 1 つが証明書 (セキュリティープリンシパル) の所有者を識別します。
  • LDAP: DN は LDAP ディレクトリーツリー内のオブジェクトの検索に使用されます。

DN の文字列表現

DN は ASN.1 で正式に定義されていますが、DN の UTF-8 文字列表現を定義する LDAP 標準もあります (RFC 2253 を参照)。文字列表現は、DN の構造を記述するための便利な基礎を提供します。

注記

DN の文字列表現は、DER でエンコードされた DN の一意の表現を 提供しません。したがって、文字列形式から DER 形式に変換される DN は、元の DER エンコーディングを常に回復するとは限りません。

DN 文字列の例

以下の文字列は、DN の一般的な例です。

C=US,O=IONA Technologies,OU=Engineering,CN=A. N. Other

DN 文字列の構造

DN 文字列は、以下の基本要素で構成されます。

OID

OBJECT IDENTIFIER (OID) は、ASN.1 の文法構造を一意に識別するバイトのシーケンスです。

属性タイプ

DN に表示される可能性のあるさまざまな属性タイプは、理論的には制限がありませんが、実際には属性タイプの小さなサブセットのみが使用されます。表B.1「一般的に使用される属性タイプ」 は、最も発生する可能性のある属性タイプのセレクションを示しています。

表B.1 一般的に使用される属性タイプ

文字列表現X.500 属性タイプデータのサイズ同等の OID

C

countryName

2

2.5.4.6

O

organizationName

1…64

2.5.4.10

OU

organizationalUnitName

1…64

2.5.4.11

CN

commonName

1…64

2.5.4.3

ST

stateOrProvinceName

1…64

2.5.4.8

L

localityName

1…64

2.5.4.7

STREET

streetAddress

  

DC

domainComponent

  

UID

userid

  

AVA

属性値のアサーション (AVA) は属性値を属性タイプに割り当てます。文字列表現では、以下の構文を使用します。

<attr-type>=<attr-value>

以下に例を示します。

CN=A. N. Other

または、同等の OID を使用して文字列表現の属性タイプを特定できます (表B.1「一般的に使用される属性タイプ」 を参照)。以下に例を示します。

2.5.4.3=A. N. Other

RDN

相対識別名 (RDN) は、DN の単一ノード (文字列表現のコンマとコンマの間に表示されるビット) を表します。技術的には RDN に複数の AVA が含まれる場合があります (正式には AVA のセットとして定義されます)。ただし、これは実際にはほとんど発生しません。文字列表現では、RDN には以下の構文があります。

<attr-type>=<attr-value>[+<attr-type>=<attr-value> ...]

(可能性としては非常に低い) 複数の値を持つ RDN の例を以下に示します。

OU=Eng1+OU=Eng2+OU=Eng3

単一値を持つ RDN の例を以下に示します。

OU=Engineering

法律上の通知

Copyright © 2021 Red Hat, Inc.
The text of and illustrations in this document are licensed by Red Hat under a Creative Commons Attribution–Share Alike 3.0 Unported license ("CC-BY-SA"). An explanation of CC-BY-SA is available at http://creativecommons.org/licenses/by-sa/3.0/. In accordance with CC-BY-SA, if you distribute this document or an adaptation of it, you must provide the URL for the original version.
Red Hat, as the licensor of this document, waives the right to enforce, and agrees not to assert, Section 4d of CC-BY-SA to the fullest extent permitted by applicable law.
Red Hat, Red Hat Enterprise Linux, the Shadowman logo, the Red Hat logo, JBoss, OpenShift, Fedora, the Infinity logo, and RHCE are trademarks of Red Hat, Inc., registered in the United States and other countries.
Linux® is the registered trademark of Linus Torvalds in the United States and other countries.
Java® is a registered trademark of Oracle and/or its affiliates.
XFS® is a trademark of Silicon Graphics International Corp. or its subsidiaries in the United States and/or other countries.
MySQL® is a registered trademark of MySQL AB in the United States, the European Union and other countries.
Node.js® is an official trademark of Joyent. Red Hat is not formally related to or endorsed by the official Joyent Node.js open source or commercial project.
The OpenStack® Word Mark and OpenStack logo are either registered trademarks/service marks or trademarks/service marks of the OpenStack Foundation, in the United States and other countries and are used with the OpenStack Foundation's permission. We are not affiliated with, endorsed or sponsored by the OpenStack Foundation, or the OpenStack community.
All other trademarks are the property of their respective owners.