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

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

独自のアプリケーションで karaf レルムを使用できます。karaf を、使用する 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 モジュールを定義するフラグ」 を参照してください。

プロパティーログインモジュールは、ユーザー名/パスワードクレデンシャルをフラットファイル形式で保存するために使用されます。プロパティーログインモジュールで新規ユーザーを作成するには、テキストエディターを使用して 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

ロールをユーザーに直接割り当てる代わりに (またはそれに加えて)、公開鍵ログインモジュールでユーザーをユーザーグループに追加するオプションもあります。公開鍵ログインモジュールでユーザーグループを作成するには、テキストエディターを使用して 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

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

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

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

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

jaas:config 要素の構文は 例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>

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

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

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 プロパティー」 に示します。

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

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

<?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 ログインモジュール」 を参照してください。

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

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

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

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

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 設定は、プロパティーログインモジュールを使用して新しい 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:* コンソールコマンドがユーザーデータを管理できるようにします。

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

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

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

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

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

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

InstallDir/etc/PersistentID.cfg

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

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

以下の 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:* コンソールを使用して設定を編集することはできません。

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

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

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

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

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

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

以下の 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:* コンソールを使用して設定を編集することはできません。

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

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

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

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

JAAS 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 サービスとしてインスタンス化およびエクスポートされた後、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>

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

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

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

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

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

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

以下の 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>

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

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

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

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

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

デフォルトでは、標準の 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 の値に一致する必要があります。

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

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

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

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

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

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

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

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

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

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

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

ロールベースアクセス制御のシステムでは、ユーザー認証データにロールを追加して、ユーザーにパーミッションを付与できます。たとえば、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

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

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

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

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

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

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

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

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

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

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

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

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

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 ファイルのコメントを参照してください。

すべての 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 ファイル 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) のみにアクセスできる事を意味します。

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 を定義すると、これらのカスタム 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「OSGi サービスのアクセス制御メカニズム」 は、Karaf コンテナーにおける OSGi サービスのロールベースアクセス制御メカニズムの概要を示しています。

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

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

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

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

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

コマンドコンソール ACL ファイルは、InstallDir/etc/auth ディレクトリーにあり、名前にプレフィックス org.apache.karaf.command.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 ファイルの各行は、次の形式のエントリーです。

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 設定を変更でき、すでにログインしているユーザーであっても、数秒以内に変更が反映されます。

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 サービス (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
  }
}

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