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 ユーザーに完全な管理権限を付与します。

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

ユーザーに直接ロールを割り当てる代わりに (またはそれに加えて)、公開鍵ログインモジュールの user groups にユーザーを追加するオプションもあります。公開鍵ログインモジュールでユーザーグループを作成するには、テキストエディターを使用して 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 メッセージダイジェストアルゴリズムを使用した基本的な暗号化が有効になります。

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 名前空間で定義されています。JAAS レルムを定義するときは、例2.1「JAAS ブループリント名前空間」 に示された行を含める必要があります。

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

jaas:config 要素の構文は 例2.2「ブループリント 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「ブループリント 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 プロパティーログインモジュールは、次のオプションをサポートしています。

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

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

次のクラスは、JAASOSGi 設定ログインモジュールを実装します。

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 ファイルは、公開鍵ログインモジュールのユーザー名、公開鍵、およびロールデータを保存するために使用されます。各ユーザーは、鍵プロパティーファイルの 1 行で表されます。この行の形式は、次のとおりです。

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 ログインモジュールは、ユーザー名/パスワードのクレデンシャルを認証し、認証されたユーザーに関連付けられたロールのリストを返します。

次のクラスは、JAASJDBC ログインモジュールを実装します。

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

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

JDBC ログインモジュールを設定する前に、ユーザーデータを格納するためにバッキングデータベースにユーザー users テーブルと roles テーブルを設定する必要があります。たとえば、以下の 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 サービスとしてエクスポートするのが正しい方法です。そうすることで、JDBC ログインモジュールは、エクスポートされた OSGi サービスを参照することにより、データソースにアクセスできるようになります。たとえば、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>

上記のブループリント設定は、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 認証チュートリアル を参照してください。

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

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

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

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

<?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 Guard は、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.cfg ファイルから)jmx.acl.hawtio.OSGiTools MBean の次の設定の場合は、以下のようになります。

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 Guard によって保護されます。ただしデフォルトでは、通常 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 設定を変更できます。したがって、システムの実行中にセキュリティー違反を発見した場合は、Karaf コンテナーを再起動しなくても、関連する ACL ファイルを編集することで、システムの特定の部分へのアクセスをすぐに制限できます。

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

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

コマンドコンソールのアクセス制御メカニズムは、実際には、OSGi サービスの一般的なアクセス制御メカニズムに基づいています。そのため、コンソールコマンドが実装され、OSGi サービスとして公開されることがあります。Karaf コンソール自体は、OSGi Service Registry を介して使用可能なコマンドを検出し、OSGi サービスとしてコマンドにアクセスします。したがって、OSGi サービスのアクセス制御メカニズムを使用して、コンソールコマンドへのアクセスを制御できます。

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

特定の OSGi サービスにサービスガードが設定されている場合、OSGi サービスでのクライアント呼び出しは次のように進行します。

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

コマンドコンソールの ACL ファイルは、接頭辞 org.apache.karaf.command.acl で InstallDir/etc/auth ディレクトリーにあります。

コマンドコンソールの 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 サービスでメソッドを呼び出す Java コードを記述する場合 (つまり、OSGi サービスのクライアントを実装する場合)、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 オブジェクトで、そのサービスでメソッドを呼び出す可能性があるすべてのロールのリストが含まれます。