Menu Close
第2章 Apache Karaf コンテナーの保護
概要
Apache Karaf コンテナーは JAAS を使用してセキュア化されます。JAAS レルムを定義することで、ユーザークレデンシャルの取得に使用されるメカニズムを設定できます。また、デフォルトのロールを変更することで、コンテナーの管理インターフェースへのアクセスを調整することもできます。
2.1. JAAS 認証
概要
Java Authentication and Authorization Service (JAAS) は、Java アプリケーションで認証を実装する一般的なフレームワークを提供します。認証の実装はモジュール化され、個々の JAAS モジュール (またはプラグイン) により認証の実装が提供されます。
JAAS の詳細は『JAAS Reference Guide』を参照してください。
2.1.1. デフォルトの JAAS レルム
ここでは、Karaf コンテナーのデフォルトの JAAS レルムのユーザーデータを管理する方法について説明します。
デフォルトの JAAS レルム
Karaf コンテナーには事前定義された JAAS レルムである karaf
レルムがあります。これはデフォルトで、コンテナーのすべての側面をセキュアにするために使用されます。
アプリケーションを JAAS と統合する方法
独自のアプリケーションで karaf
レルムを使用できます。karaf
を、使用する JAAS レルムの名前として設定するだけです。
デフォルトの JAAS ログインモジュール
Karaf コンテナーを初めて起動する場合、karaf
デフォルトレルムを使用するように設定されています。このデフォルト設定では、karaf
レルムは 5 つの JAAS ログインモジュールをデプロイし、同時に有効にします。デプロイされたログインモジュールを表示するには、以下のように jaas:realms
コンソールコマンドを入力します。
Index │ Realm Name │ Login Module Class Name ──────┼────────────┼─────────────────────────────────────────────────────────────── 1 │ karaf │ org.apache.karaf.jaas.modules.properties.PropertiesLoginModule 2 │ karaf │ org.apache.karaf.jaas.modules.publickey.PublickeyLoginModule 3 │ karaf │ org.apache.karaf.jaas.modules.audit.FileAuditLoginModule 4 │ karaf │ org.apache.karaf.jaas.modules.audit.LogAuditLoginModule 5 │ karaf │ org.apache.karaf.jaas.modules.audit.EventAdminAuditLoginModule
ユーザーがログインを試みるたびに、認証は 5 つのモジュールを一覧順に処理します。各モジュールのフラグ値は、認証を成功させるためにモジュールが正常に完了する必要があるかどうかを指定します。フラグ値は、モジュールの完了後に認証プロセスを停止するか、または次のモジュールに進むかどうかも指定します。
Optional
フラグは、5 つの認証モジュールすべてに設定されます。Optional
フラグ設定により、現在のモジュールが正常に完了するかどうかにかかわらず、認証プロセスが常に 1 つのモジュールから次のモジュールに渡されます。Karaf JAAS レルムのフラグ値はハードコーディングされており、変更はできません。フラグの詳細については、表2.1「JAAS モジュールを定義するフラグ」 を参照してください。
Karaf コンテナーでは、プロパティーログインモジュールと公開鍵ログインモジュールの両方が有効になります。JAAS がユーザーを認証するとき、最初にプロパティーログインモジュールでユーザーの認証を試みます。これに失敗すると、公開鍵ログインモジュールでユーザーを認証しようとします。そのモジュールも失敗すると、エラーが発生します。
2.1.1.1. 認証監査ロギングモジュール
Karaf コンテナーのデフォルトモジュールのリスト内で、最初の 2 つのモジュールのみがユーザーアイデンティティーの検証に使用されます。残りのモジュールは、成功および失敗したログイン試行の監査証跡をログに記録するために使用されます。デフォルトのレルムには、以下の監査ロギングモジュールが含まれます。
- org.apache.karaf.jaas.modules.audit.LogAuditLoginModule
-
このモジュールは、
etc/org.ops4j.pax.logging.cfg
ファイル内の Pax ロギングインフラストラクチャーに設定されたロガーを使用して、認証の試行に関する情報を記録します。詳細は、「JAAS ログ監査ログインモジュール」を参照してください。 - org.apache.karaf.jaas.modules.audit.FileAuditLoginModule
- このモジュールは、認証試行に関する情報を指定したファイルに直接記録します。ロギングインフラストラクチャーを使用しません。詳細は、「JAAS ファイル監査ログインモジュール」を参照してください。
- org.apache.karaf.jaas.modules.audit.EventAdminAuditLoginModule
- このモジュールは、OSGi Event Admin サービスを使用して認証の試行を追跡します。
プロパティーログインモジュールでのユーザーの設定
プロパティーログインモジュールは、ユーザー名/パスワードクレデンシャルをフラットファイル形式で保存するために使用されます。プロパティーログインモジュールで新規ユーザーを作成するには、テキストエディターを使用して InstallDir/etc/users.properties
ファイルを開き、以下の構文の行を追加します。
Username=Password[,UserGroup|Role][,UserGroup|Role]...
たとえば、パスワード topsecret
およびロール admin
で jdoe
ユーザーを作成するには、以下のようなエントリーを作成します。
jdoe=topsecret,admin
ここで、admin
ロールは jdoe
ユーザーに完全な管理権限を付与します。
プロパティーログインモジュールでのユーザーグループの設定
ロールをユーザーに直接割り当てる代わりに (またはそれに加えて)、プロパティーログインモジュールでユーザーをユーザーグループに追加するオプションもあります。プロパティーログインモジュールでユーザーグループを作成するには、テキストエディターを使用して InstallDir/etc/users.properties
ファイルを開き、以下の構文の行を追加します。
_g_\:GroupName=Role1,Role2,...
たとえば、ロール group
および admin
で admingroup
ユーザーグループを作成するには、以下のようなエントリーを作成します。
_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
および admin
で admingroup
ユーザーグループを作成するには、以下のようなエントリーを作成します。
_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
レルムをすべてオーバーライドするように、rank
を100
以上に設定する必要があります。
-
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 クエリーを使用して関連データベースの更新を実行します) 。
複数のログインモジュールを各ログインモジュールと組み合わせて、認証コンポーネントと承認コンポーネントの両方を提供できます。たとえば、デフォルトの PropertiesLoginModule
と JDBCLoginModule
を組み合わせて、システムへのアクセスを確実にすることができます。
ユーザーグループは 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=system
DN に空白文字が含まれる場合、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 グループ
admin
、devop
、および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.url
が ldaps:// で始まる場合は、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=(&(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=(&(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.protocol
を TLSv1
以降に設定する必要があります。
異なるディレクトリーサーバーのフィルター設定
ディレクトリーサーバー間の最も重要な違いは、LDAP ログインモジュールでフィルターオプションを設定することに関連しています。正確な設定は、最終的に DIT の組織によって異なりますが、次の表で異なるディレクトリーサーバーに必要な一般的なロールフィルター設定について説明します。
ディレクトリーサーバー | 一般的なフィルター設定 |
---|---|
389-DS Red Hat DS |
user.filter=(&(objectClass=InetOrgPerson)(uid=%u)) role.filter=(uniquemember=%fqdn) |
MS Active Directory |
user.filter=(&(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 演算子を表す) は &
としてエスケープ処理されます。
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.cfg
は org.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.cfg
の Audit 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.audit
や com.example.audit
など、Apache Log4J ライブラリーと Log4J2 ライブラリーによって確立される標準のロガー (カテゴリー) 名のドット区切り形式を表します。<level>`
は、WARN
、INFO
、TRACE
、または 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 つあります。
-
encryption.name = basic
(説明は 「Basic 暗号化サービス」 を参照) -
encryption.name = jasypt
(説明は 「Jasypt 暗号化」 を参照)
独自の暗号化サービスを作成することもできます。これを実行するには、以下が必要です。
-
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
設定ファイルを変更することで、暗号化を有効にできます。
機能
jasypt-encryption
をインストールします。これにより、jasypt
サービスがインストールされます。karaf@root> features:install jasypt-encryption
これで、
jaas
コマンドを使用してユーザーを作成できます。$FUSE_HOME/etc/org.apache.karaf.jaas.cfg
ファイルを開き、以下のように変更します。encryption.enabled = true
、encryption.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
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
以下のコマンドを実行してユーザーを作成します。
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
ここで、
$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
-
既に
jaas:update
コマンドを実行しているので、新たに作成したログインを別のターミナルでテストできます。
2.1.11. HTTP Basic 認証による JAAS インテグレーション
Servlet REST を使用して、REST DSL を使用する Camel ルートに REST エンドポイントを定義できます。以下の例は、HTTP Basic 認証によって保護される REST エンドポイントが Karaf JAAS サービスにユーザー認証を委譲する方法を示しています。
手順
Apache Camel を
CamelInstallDir
にインストールした場合、以下のディレクトリーでサンプルを見つけることができます。CamelInstallDir/examples/camel-example-servlet-rest-karaf-jaas
Maven を使用してサンプルを OSGi バンドルとしてビルドおよびインストールします。コマンドプロンプトを開き、現在のディレクトリーを
CamelInstallDir/examples/camel-example-servlet-rest-karaf-jaas
に切り替えて、以下のコマンドを入力します。mvn install
セキュリティー設定ファイルを
KARAF_HOME/etc
フォルダーにコピーするには、以下のコマンドを入力します。cp src/main/resources/org.ops4j.pax.web.context-camelrestdsl.cfg $KARAF_HOME/etc
Karaf に Apache Camel をインストールするには、Karaf シェルコンソールで以下のコマンドを入力します。
feature:repo-add camel ${project.version} feature:install camel
camel-servlet
、camel-jackson
、およびwar
Karaf 機能も必要で、以下のコマンドを入力してこれらの機能をインストールします。feature:install camel-servlet feature:install camel-jackson feature:install war
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) 機能について説明します。標準のロール (manager
、admin
など) をユーザーのクレデンシャルに追加すると、すぐに 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 アクセス制御の標準ロール
ロール | 説明 |
---|---|
| Karaf コンテナーへの読み取り専用アクセスを付与します。 |
| アプリケーションをデプロイおよび実行する通常のユーザーに、適切なレベルで読み書きアクセスを付与します。ただし、機密性の高い Karaf コンテナー設定へのアクセスはブロックされます。 |
| Karaf コンテナーへの無制限のアクセスを付与します。 |
| 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 のアクセス制御メカニズム

仕組み
JMX アクセス制御は、特別な javax.management.MBeanServer
オブジェクトを介して JMX へのリモートアクセスを提供することで動作します。このオブジェクトは、JMX ガードと呼ばれる org.apache.karaf.management.KarafMBeanServerGuard
オブジェクトを呼び出して、プロキシーとして機能します。JMX ガードは、起動ファイルに特別な設定なしで利用できます。
JMX アクセス制御は、以下のように適用されます。
- ローカルでない JMX 呼び出しごとに、実際の MBean 呼び出しの前に JMX ガードが呼び出されます。
- JMX ガードは、ユーザーがアクセスしようとしている MBean の関連する ACL を検索します (ACL は OSGi Config Admin サービスに保存されます)。
- ACL は、MBean でこの特定の呼び出しを実行できるロールのリストを返します。
- JMX ガードは、現在のセキュリティーサブジェクト (JMX 呼び出しを行ったユーザー) に対してロールのリストをチェックし、現在のユーザーに必要なロールがあるかどうかを調べます。
-
一致するロールが見つからない場合、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 サービスのアクセス制御メカニズム

仕組み
実際には、コマンドコンソールのアクセス制御のメカニズムは、OSGi サービスの汎用アクセス制御メカニズムに基づいています。コンソールコマンドは OSGi サービスとして実装および公開されます。Karaf コンソール自体は OSGi サービスレジストリーを介して利用可能なコマンドを検出し、OSGi サービスとしてコマンドにアクセスします。そのため、OSGi サービスのアクセス制御メカニズムを使用して、コンソールコマンドへのアクセスを制御できます。
OSGi サービスを保護するためのメカニズムは、OSGi Service Registry Hooks に基づいています。これは、特定のコンシューマーから OSGi サービスを隠し、OSGi サービスをプロキシーサービスに置き換えることができる高度な OSGi 機能です。
特定の OSGi サービスに対してサービスガードが配置されていると、OSGi サービス上のクライアント呼び出しは次のように続行されます。
- 呼び出しは、要求された OSGi サービスに直接送信されません。代わりに、リクエストは代替プロキシーサービスにルーティングされます。このサービスには、元のサービスと同じサービスプロパティー (および追加のサービス) があります。
- サービスガードは、ターゲット OSGi サービスに関連する ACL を検索します (ACL は OSGi Config Admin サービスに保存されます)。
- ACL は、サービスでこの特定のメソッド呼び出しを実行できるロールのリストを返します。
-
このコマンドの ACL が見つからない場合、サービスガードはデフォルトで
etc/system.properties
ファイルのkaraf.secured.command.compulsory.roles
プロパティーに指定されたロールのリストになります。 - サービスガードは、現在のセキュリティーサブジェクト (メソッド呼び出しを行ったユーザー) に対してロールのリストをチェックし、現在のユーザーに必要なロールがあるかどうかを調べます。
-
一致するロールが見つからない場合、メソッド呼び出しがブロックされ、
SecurityException
が発生します。 - または、一致するロールが見つかると、メソッド呼び出しは元の 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 を定義するには、以下の手順を実行します。
Java インターフェースを使用して OSGi サービスを定義するのが通例です (通常の Java クラスを使用することもできますが、これは推奨されません)。たとえば、OSGi サービスとして公開する予定の Java インターフェース
MyService
について考えてみましょう。package org.example; public interface MyService { void doit(String s); }
Java インターフェースを OSGi サービスとして公開するには、通常
service
要素を OSGi Blueprint XML ファイルに追加します (Blueprint XML ファイルは通常、Maven プロジェクトのsrc/main/resources/OSGI-INF/blueprint
ディレクトリーに保存されます)。たとえば、MyServiceImpl
がMyService
インターフェースを実装するクラスであると仮定すると、以下のように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>
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 サービスは、実際には、このファイルのプロパティー設定で指定されます (次のステップを参照)。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
最後に、この 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 設定ファイルで暗号化されたプロパティープレースホルダーを使用します。
前提条件
- 値を暗号化するためマスターパスワードを知っている。
手順
デフォルトの暗号化アルゴリズム
PBEWithMD5AndDES
を使用するか、使用する暗号化アルゴリズムを次のように選択します。jasypt:list-algorithms
コマンドを実行して、現在の Java 環境でサポートされるアルゴリズムを検出します。karaf@root()> jasypt:list-algorithms
引数やオプションはありません。この出力は、サポートされるダイジェストおよび Password Based Encryption (PBE) アルゴリズムの識別子のリストです。このリストには、Fuse 7.9 の一部である Bouncy Castle ライブラリーによって提供されるアルゴリズムが含まれています。このリストは長くなる可能性があります。この一部は以下のようになります。
karaf@root()> jasypt:list-algorithms DIGEST ALGORITHMS: - 1.0.10118.3.0.55 - 1.2.804.2.1.1.1.1.2.2.1 ... - 2.16.840.1.101.3.4.2.9 - BLAKE2B-160 - BLAKE2B-256 ... - MD4 - MD5 - OID.1.0.10118.3.0.55 ... - SHA3-512 - SKEIN-1024-1024 - SKEIN-1024-384 ... - TIGER - WHIRLPOOL PBE ALGORITHMS: - PBEWITHHMACSHA1ANDAES_128 - PBEWITHHMACSHA1ANDAES_256 ... - PBEWITHSHA1ANDRC2_128 - PBEWITHSHA1ANDRC2_40 ... - PBEWITHSHAANDIDEA-CBC - PBEWITHSHAANDTWOFISH-CBC
- リストを確認し、使用する暗号化アルゴリズムの識別子を見つけます。セキュリティーの専門家に相談してアルゴリズムを選択することをお勧めします。
設定ファイルで使用するパスワードなど、機密性の高い設定値を暗号化するには、
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
jasypt:encrypt
コマンドを実行して、取得した暗号化された値が含まれるプロパティーファイルを作成します。ENC()
関数で暗号化された各値をラップします。たとえば、一部の LDAP クレデンシャルを
etc/ldap.properties
ファイルに保存する場合は、ファイルの内容は次のようになります。#ldap.properties ldap.password=ENC(VMJ5S566MEDhQ5r6jiIqTB+fao3NN4pKnQ9xU0wiDCg=) ldap.url=ldap://192.168.1.74:10389
暗号化されたプロパティープレースホルダーに必要な 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>
使用した 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
コマンドを実行します。
デフォルトの動作を変更するには、以下のオプションのいずれかを指定します。
オプション | 説明 | 例 |
---|---|---|
|
このオプションの後に、
|
例: |
| このオプションの後に、初期ダイジェストのハッシュを繰り返し作成する回数を示す整数を指定します。各繰り返しは前のハッシュ結果を取り、再度ハッシュします。結果は最終的なダイジェストです。デフォルトは 1000 です。 |
例: |
|
このオプションの後に、 |
例: |
| このオプションを指定して 16 進数の出力を取得します。デフォルトの出力は Base64 です。 |
例: |
| コマンド構文およびオプションに関する情報を表示します。 |
|
ダイジェストの取得後、「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
) を使用して復号化キーを作成します。次に、このコマンドはこの復号化キーを使用して、プロンプトで入力する値を復号化します。
デフォルトの動作を変更するには、以下のオプションのいずれかを指定します。
オプション | 説明 | 例 |
---|---|---|
| このオプションの後にマスターパスワードの値に設定された環境変数またはシステムプロパティーを指定します。Jasypt はこの値を復号化アルゴリズムとともに使用して、最初の復号化キーを取得します。
|
|
| このオプションの後に選択したマスターパスワードのプレーンテキスト値を指定します。マスターパスワードのプレーンテキスト値は履歴に表示されます。 Jasypt はこの値を復号化アルゴリズムとともに使用して、最初の復号化キーを取得します。
|
|
|
このオプションの後に、
|
例: |
| このオプションの後に、初期キーのハッシュを繰り返し作成する回数を示す整数を指定します。各繰り返しは前のハッシュ結果を取り、再度ハッシュします。結果は最終的な復号化キーになります。デフォルトは 1000 です。
|
例: |
| このオプションを指定して 16 進数の出力を取得します。デフォルトの出力は Base64 です。 |
例: |
| 以前のバージョンの Jasypt で暗号化したパスワードを復号化するために、固定された IV ジェネレーターを使用します。 |
例: |
| コマンド構文およびオプションに関する情報を表示します。 |
|
環境変数またはシステムプロパティーを指定する例
値を復号化する際にプレーンテキストのマスターパスワードを指定するのではなく、マスターパスワードに設定される環境変数またはシステムプロパティーを指定できます。たとえば、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 ファイルの作成およびデプロイ
-
任意の XML エディターを使用して、
keystore.xml
ファイルを作成し、<installDir>/jboss-fuse-7.8.0.fuse-780038-redhat-00001/etc
ディレクトリーに保存します。 このテキストをファイルに追加します。
<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>
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) から保護するには、secureProtocol
を TLSv1
に設定する必要があります。
必要に応じて、enabledCipherSuites
プロパティーを設定して、JMX TLS 接続に使用する特定の暗号スイートをリストできます。このプロパティーを設定すると、デフォルトの暗号スイートが上書きされます。
Karaf コンテナーの再起動
新しい JMX SSL/TLS 設定を有効にするには、Karaf コンテナーを再起動する必要があります。
セキュアな JMX 接続のテスト
コマンドプロンプトを開き、現在の場所が Fuse インストールの
etc/
ディレクトリーであることを確認します。cd <installDir>/jboss-fuse-7.8.0.fuse-780038-redhat-00001/etc
ターミナルを開き、以下のコマンドを実行して 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 が正常に有効になっていることを確認できます。重要同じコマンドラインでコマンド全体を入力します。
-
JConsole が開いたら、
New Connection
ウィザードでRemote Process
オプションを選択します。 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
コマンドの呼び出しに関する情報を参照してください。
手順
クレデンシャルストアパスワードを選択します。
後で値をクレデンシャルストアに追加する場合や、値を復号化する場合、クレデンシャルストアコマンドはクレデンシャルストアパスワードを使用して値を暗号化および復号化します。
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=
以下のように
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
etc/system.properties
ファイルのエントリーを更新するか、新しいエントリーを追加します。更新または追加するエントリーは、credential-store:store
コマンドで指定したエイリアスを、コマンドが出力する参照値に設定します。以下に例を示します。db.password = CS:db.password
Fuse が設定されたクレデンシャルストアで稼働している場合、
db.password
システムプロパティーなどの各インスタンスを、クレデンシャルストアにある実際のシークレット値に動的に置き換えます。-
credential-store:store
コマンドでは、指定したエイリアスが既に使用されているシステムプロパティーである場合は、次のステップをスキップします。シークレットに指定したエイリアスがコードで使用されていない場合、シークレットを必要とする各ファイルで、直前の手順でシステムプロパティーとして追加したエイリアスを指定します。たとえば、コードはdb.password
を参照します。 - クレデンシャルストアに追加する値ごとに、前述の 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 を使用してこれを確認すると、クレデンシャルストアの値は非表示になります。

2.5.3. クレデンシャルストアシステムプロパティーおよび環境変数の説明
システムプロパティーまたは環境変数を使用して、クレデンシャルストアの設定パラメーターを保持できます。クレデンシャルストアの作成時に指定するオプションにより、以下が決定されます。
- プロパティーまたは変数を独自に設定する必要があるかどうか。
- プロパティーまたは変数が設定されている、または設定する必要がある正確な値。
プロパティー/変数を理解すると、クレデンシャルストアが機能する仕組みを理解するのに役立ちます。
credential-store:create
コマンドを実行し、--persist
オプションのみを指定すると、コマンドはシステムプロパティーをクレデンシャルストア設定パラメーターに設定します。クレデンシャルストアのシステムプロパティーを明示的に設定する必要はありません。
代わりにクレデンシャルストアの環境変数を使用するか、credential-store:create
コマンドのデフォルト動作を変更する場合、クレデンシャルストアの作成時に指定できるオプションに関する詳細は、credential-store:create
コマンドリファレンス を参照してください。
クレデンシャルストアを作成するコマンドを実行すると、指定するオプションによってクレデンシャルストアプロパティーまたは変数の設定が決定されます。プロパティーまたは変数を独自に設定する必要がある場合、credential-store:create
コマンドの出力には、その手順が含まれます。つまり、クレデンシャルストアのシステムプロパティーまたは環境変数の設定をユーザーが決定することはできません。credential-store:create
コマンドを実行すると常に設定が決定されます。
以下の表は、クレデンシャルストアのプロパティーおよび変数を示しています。特定のパラメーターでは、環境変数とシステムプロパティーの両方が設定されている場合、環境変数の設定が優先されます。
名前 | 説明 |
---|---|
環境変数:
システムプロパティー: | クレデンシャルストアが暗号化キーを取得するために使用する PBE (Password Based Encryption) アルゴリズム。 |
環境変数:
システムプロパティー: | クレデンシャルストアの場所。 |
環境変数:
システムプロパティー: | クレデンシャルストアが暗号化キーを取得するために使用するパラメーター。パラメーターには、反復回数、初期ベクトル、salt が含まれます。 |
環境変数:
システムプロパティー: |
クレデンシャルストアからパスワードやその他のセキュアなデータをリカバリーするために、クレデンシャルストアコマンドが復号化する必要があるパスワード。 |
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
でのクレデンシャルストアの特定 - クレデンシャルストア設定は保存しない
以下の表は、デフォルトの動作を変更するために指定できるオプションを示しています。
オプション | 説明 |
---|---|
| このオプションの後にマスターパスワードの値に設定された環境変数またはシステムプロパティーを指定します。クレデンシャルストアは、この値をアルゴリズムとともに使用して、暗号化または復号化キーを取得します。
例: |
| このオプションの後に選択したマスターパスワードのプレーンテキスト値を指定します。マスターパスワードのプレーンテキスト値は履歴に表示されます。 クレデンシャルストアは、この値をアルゴリズムとともに使用して、暗号化または復号化キーを取得します。
例: |
| クレデンシャルストアの作成を強制します。クレデンシャルストアが新しいクレデンシャルストアの目的の場所にある場合、このオプションを指定するとコマンドは既存のクレデンシャルストアを上書きします。既存のクレデンシャルストアの内容はすべて失われます。 デフォルトの動作では、目的の場所にクレデンシャルストアがすでにある場合、コマンドはクレデンシャルストアを作成しません。 |
|
新しいクレデンシャルストアの場所を指定します。デフォルトの場所である |
| このオプションの後に、使用されている暗号化アルゴリズムを繰り返し適用する回数を示す整数を指定します。繰り返しごとに前の結果を取り、再度アルゴリズムを適用します。結果は、最終的なマスクされたパスワードです。デフォルトは 200000 です。 |
|
このオプションの後に、マスクされたパスワードを生成するために |
|
新しいクレデンシャルストアの設定を
このオプションを省略する理由は、クレデンシャルストアの設定パラメーターの値を確認するためです。または、 |
| コマンド構文およびオプションに関する情報を表示します。 |
--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 起動時の挙動
felix.configadmin
バンドル:-
felix.cm.pm
プロパティーが設定されているため、ConfigurationAdmin
サービスの登録が遅延します。 -
name=cm
OSGi サービス登録プロパティーで、org.apache.felix.cm.PersistenceManagerOSGi
サービスが利用可能になるのを待ちます。
-
Fuse クレデンシャルストアバンドル:
-
credential.store.
* システムプロパティーまたはCREDENTIAL_STORE_
* 環境変数に設定した値を使用して、クレデンシャルストアをロードします。 -
org.apache.felix.cm.PersistenceManagerOSGi
サービスを実装する OSGi サービスを登録します。
何らかの障害が発生した場合、クレデンシャルストアバンドルは
PersistenceManager
サービスを登録しますが、特別なことはしません。何かが正常でない場合や、クレデンシャルストアが利用できない場合は、Fuse は暗号化されていない設定値を読み取りできるはずです。CS:
プレフィックスで指定した暗号化された値は、元の値を覚えているか、クレデンシャルストアとその設定を復旧できる場合以外は失われます。-
-
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