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

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 オブジェクトで、そのサービスでメソッドを呼び出す可能性があるすべてのロールのリストが含まれます。