検索

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

download PDF

概要

このセクションでは、Karaf コンテナーでデフォルトで有効になっているロールベースのアクセス制御 (RBAC) 機能について説明します。標準のロール (manageradmin など) をユーザーのクレデンシャルに追加すると、すぐに RBAC 機能を活用できます。より高度な使用法として、各ロールが実行できることを正確に制御するために、アクセス制御リストをカスタマイズするオプションがあります。独自の OSGi サービスにカスタム ACL を適用するオプションもあります。

2.2.1. ロールベースのアクセス制御の概要

デフォルトでは、Fuse ロールベースアクセス制御は、Fuse 管理コンソール、JMX 接続、および Karaf コマンドコンソールを介したアクセスを保護します。デフォルトのアクセス制御レベルを使用するには、ユーザー認証データに標準ロールを追加します (例: users.properties ファイルを編集して)。関連するアクセス制御リスト (ACL) ファイルを編集して、アクセス制御をカスタマイズするオプションもあります。

メカニズム

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

JMX Guard
Karaf コンテナーは JMX ガードで設定されています。このガードは、受信するすべての JMX 呼び出しをインターセプトし、設定された JMX アクセス制御リストを介して呼び出しをフィルターリングします。JMX ガードは JVM レベルで設定されているため、例外なく すべての JMX 呼び出しをインターセプトします。
OSGi サービスガード
いずれの OSGi サービスでも、OSGi サービスガードを設定できます。OSGi サービスガードはプロキシーオブジェクトとして実装され、クライアントと元の OSGi サービスの間に介入します。OSGi サービスガードは、OSGi サービスごとに明示的に設定する必要があり、デフォルトではインストールされません (事前設定されている Karaf コンソールコマンドを表す OSGi サービスを除く)。

保護タイプ

ロールベースのアクセス制御の Fuse 実装は、次のタイプの保護を提供できます。

Fuse Console (Hawtio)
Fuse Console (Hawtio) を介したコンテナーアクセスは、JMXACL ファイルによって制御されます。Fuse Console を提供する REST/HTTP サービスは、JMX の上に階層化された Jolokia テクノロジーを使用して実装されます。したがって、最終的に、すべての Fuse Console 呼び出しは JMX を通過し、JMXACL によって規制されます。
JMX
Karaf コンテナーの JMX ポートへの直接アクセスは、JMX ACL によって規制されています。さらに、JMX ガードは JVM レベルで設定されているため、Karaf コンテナーで実行されているアプリケーションによって開かれた追加の JMX ポートも JMX ACL によって規制されます。
Karaf コマンドコンソール

Karaf コマンドコンソールへのアクセスは、コマンドコンソール ACL ファイルによって規制されます。Karaf コンソールへのアクセス方法に関係なく、アクセス制御が適用されます。Fuse Console と SSH プロトコルのどちらを使用してコマンドコンソールにアクセスしても、アクセス制御が適用されます。

注記

コマンドラインで Karaf コンテナーを直接起動し (./bin/fuse スクリプトを使用するなどして)、ユーザー認証が実行されない特別なケースでは、etc/system.properties ファイルの karaf.local.roles プロパティーで指定されたロールを自動的に取得します。

OSGi サービス
Karaf コンテナーにデプロイされた OSGi サービスの場合、オプションで ACL ファイルを有効にできます。これにより、メソッド呼び出しは特定のロールに制限されます。

ロールのユーザーへの追加

ロールベースのアクセス制御システムでは、ユーザー認証データにロールを追加することにより、ユーザーにパーミッションを与えることができます。たとえば、etc/users.properties ファイルの以下のエントリーは admin ユーザーを定義し、admin ロールを割り当てます。

admin = secretpass,group,admin,manager,viewer,systembundles,ssh

また、ユーザーグループを定義してから、ユーザーを特定のユーザーグループに割り当てるオプションもあります。たとえば、以下のように admingroup ユーザーグループを定義および使用できます。

admin = secretpass, _g_:admingroup

_g_\:admingroup = group,admin,manager,viewer,systembundles,ssh
注記

ユーザーグループは、すべてのタイプの JAAS ログインモジュールでサポートされているわけではありません。

標準のロール

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

表2.2 アクセス制御の標準的なロール
ロール説明

viewer

Karaf コンテナーへの読み取り専用アクセスを許可します。

manager

アプリケーションのデプロイや実行を行う通常のユーザーに、適切なレベルで読み取り/書き込みアクセスを許可します。ただし、機密性の高い Karaf コンテナー設定オプションへのアクセスをブロックします。

admin

Karaf コンテナーへのアクセスを無制限に許可します。

ssh

Karaf コマンドコンソールに (ssh ポート経由で) 接続する権限をユーザーに付与します。

ACL ファイル

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

etc/auth/jmx.acl[.*].cfg
JMX ACL ファイル。
etc/auth/org.apache.karaf.command.acl.*.cfg
コマンドコンソール ACL ファイル。

ロールベースアクセス制御のカスタマイズ

デフォルトでは、JMX ACL ファイルとコマンドコンソール ACL ファイルの完全なセットが提供されます。システム要件に合わせ、必要に応じてこれらの ACL を自由にカスタマイズできます。詳しい方法は、次のセクションに記載されています。

アクセス制御に使用する追加プロパティー

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

karaf.local.roles
ユーザーが Karaf コンテナーコンソールを (たとえば、スクリプトを実行して) ローカルで 起動するときに適用されるロールを指定します。
hawtio.roles
Fuse Console を介して Karaf コンテナーにアクセスできるロールを指定します。この制約は、JMX ACL ファイルで定義されたアクセス制御に 加えて 適用されます。
karaf.secured.command.compulsory.roles
コンソールコマンドが etc/auth/org.apache.karaf.command.acl.*.cfg コマンド ACL ファイルによって明示的に設定されていない場合に、Karaf コンソールコマンドの呼び出しに必要なデフォルトのロールを指定します。コマンドを呼び出すには、リストにあるロールの少なくとも 1 つを使用してユーザーを設定する必要があります。値は、ロールのコンマ区切りリストとして指定されます。

2.2.2. JMX ACL のカスタマイズ

JMX ACL は OSGi Config Admin Service に保存され、通常はファイル etc/auth/jmx.acl.*.cfg としてアクセスできます。このセクションでは、JMX ACL ファイルを自分で編集して JMX ACL をカスタマイズする方法について説明します。

アーキテクチャー

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

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

rbac 01

仕組み

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

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

  1. 非ローカルの JMX 呼び出しごとに、実際の MBean 呼び出しの前に JMX ガードが呼び出されます。
  2. JMX Guard は、ユーザーがアクセスしようとしている MBean に関連する ACL を検索します (ACL は OSGi Config Admin サービスに格納されています)。
  3. ACL は、MBean でこの特定の呼び出しを行うことが許可されているロールのリストを返します。
  4. JMX Guard は、ロールリストを現在のセキュリティーサブジェクト (JMX 呼び出しを行っているユーザー) と照合して、現在のユーザーが必要なロールのいずれかを持っているか確認します。
  5. 一致するロールが見つからない場合、JMX 呼び出しがブロックされ、SecurityException が発生します。

JMX ACL ファイルの場所

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

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

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

MBean を ACL ファイル名にマッピング

JMX 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

ACL ファイル形式

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

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 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.3. コマンドコンソール ACL のカスタマイズ

コマンドコンソール ACL は OSGi Config Admin Service に保存され、通常はファイル etc/auth/org.apache.karaf.command.acl.*.cfg としてアクセスできます。このセクションでは、コマンドコンソール ACL ファイルを自分で編集してコマンドコンソール ACL をカスタマイズする方法について説明します。

アーキテクチャー

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

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

rbac 02

仕組み

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

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

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

  1. 呼び出しは、要求された OSGi サービスに直接送信 されません。代わりに、要求は、元のサービスと同じサービスプロパティー (およびいくつかの追加) を持つ置換プロキシーサービスにルーティングされます。
  2. サービスガードは、ターゲット OSGi サービスに関連する ACL を検索します (ACL は OSGi Config Admin サービスに格納されています)。
  3. ACL は、サービスでこの特定のメソッド呼び出しを行うことが許可されているロールのリストを返します。
  4. このコマンドの ACL が見つからない場合、サービスガードはデフォルトで etc/system.properties ファイルの karaf.secured.command.compulsory.roles プロパティーに指定されたロールのリストになります。
  5. サービスガードは、ロールリストを現在のセキュリティーサブジェクト (メソッド呼び出しを行っているユーザー) と照合して、現在のユーザーが必要なロールのいずれかを持っているか確認します。
  6. 一致するロールが見つからない場合、メソッド呼び出しがブロックされ、SecurityException が発生します。
  7. または、一致するロールが見つかった場合、メソッド呼び出しは元の OSGi サービスに委譲されます。

デフォルトのセキュリティーロールの設定

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

コマンドコンソール ACL ファイルの場所

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

コマンドスコープを ACL ファイル名にマッピング

コマンドコンソールの ACL ファイル名は、次の規則に従います。

etc/auth/org.apache.karaf.command.acl.CommandScope.cfg

CommandScope は、Karaf コンソールコマンドの特定グループの接頭辞に対応します。たとえば、feature:install および features:uninstall コマンドは、対応する ACL ファイル (org.apache.karaf.command.acl.features.cfg) を持つ feature コマンドスコープに属します。

ACL ファイル形式

コマンドコンソール ACL ファイルの各行は、次の形式のエントリーです。

Pattern = Role1[,Role2][,Role3]...

Pattern は、現在のコマンドスコープから Karaf コンソールコマンドと一致するパターンで、等号記号の右側は、その呼び出しを行うユーザー権限を付与するロールのコンマ区切りリストです。最も単純なケースでは、Pattern は、単にスコープのないコマンド名です。たとえば、org.apache.karaf.command.acl.feature.cfg ACL ファイルには、feature コマンドの以下のルールが含まれます。

list = admin, manager, viewer
repo-list = admin, manager, viewer
info = admin, manager, viewer
version-list = admin, manager, viewer
repo-refresh = admin, manager
repo-add = admin, manager
repo-remove = admin, manager
install = admin
uninstall = admin
重要

特定のコマンド名に一致するものが見つからない場合、そのコマンドにロールは不要であると見なされており、任意のユーザーが呼び出すことができます。

特定の引数または正規表現に一致する引数で呼び出されたコマンドに一致するパターンも定義できます。たとえば、org.apache.karaf.command.acl.bundle.cfg ACL ファイルはこの機能を利用して、通常のユーザーが -f (force) フラグで bundle:start コマンドと bundle:stop コマンドを呼び出さないようにします (システムバンドルを管理するために指定する必要があります)。この制限は、ACL ファイルで次のようにコーディングされています。

start[/.*[-][f].*/] = admin
start = admin, manager
stop[/.*[-][f].*/] = admin
stop = admin, manager

この場合、manager ロールには、通常 bundle:start および bundle:stop コマンドを呼び出す権限がありますが、admin ロールのみが force オプション -f でこれらのコマンドを呼び出す権限を持ちます。

ACL ファイルフォーマットの詳細は、etc/auth/org.apache.karaf.command.acl.bundle.cfg ファイルのコメントを参照してください。

実行時の動的設定

コマンドコンソールの ACL 設定は完全に動的です。つまり、システム実行中に ACL 設定を変更でき、すでにログオンしているユーザーであっても、変更は数秒以内に反映されます。

2.2.4. OSGi サービスの ACL 定義

任意の OSGi サービス (システムレベルまたはアプリケーションレベル) のカスタム ACL を定義することができます。デフォルトでは、OSGi サービスでアクセス制御は有効になっていません (コマンドコンソール ACL ファイルで事前に設定されている Karaf コンソールコマンドを公開する OSGi サービスを除く)。このセクションでは、OSGi サービスのカスタム ACL を定義する方法と、指定されたロールを使用してそのサービスでメソッドを呼び出す方法について説明します。

ACL ファイル形式

OSGi サービス ACL ファイルには、次のように、その ACL が適用される OSGi サービスを識別する 1 つの特別なエントリーがあります。

service.guard = (objectClass=InterfaceName)

service.guard の値は、一致する OSGi サービスを選択するために OSGi サービスプロパティーのレジストリーに適用される LDAP 検索フィルターです。最も単純なフィルタータイプ (objectClass=InterfaceName) は、指定された Java インターフェイス名 InterfaceName で OSGi サービスを選択します。

ACL ファイルの残りのエントリーは、次の形式です。

Pattern = Role1[,Role2][,Role3]...

Pattern は、サービスメソッドと一致するパターンで、等号記号の右側は、その呼び出しを行う権限をユーザーに付与するロールのコンマ区切りリストです。これらのエントリーの構文は、基本的に JMX ACL ファイルのエントリーと同じです。これについては、「ACL ファイル形式」 を参照してください。

カスタム OSGi サービスの ACL を定義する方法

カスタム OSGi サービスの ACL を定義するには、以下の手順を実行します。

  1. 一般的には、Java インターフェイスを使用して OSGi サービスを定義します (通常の Java クラスを使用することもできますが、お勧めしません)。たとえば、OSGi サービスとして公開する予定の Java インターフェイス MyService について考えてみましょう。

    package org.example;
    
    public interface MyService {
      void doit(String s);
    }
  2. Java インターフェイスを OSGi サービスとして公開するには、通常 service 要素を OSGi Blueprint XML ファイルに追加します (Blueprint XML ファイルは通常、Maven プロジェクトの src/main/resources/OSGI-INF/blueprint ディレクトリーに保存されます)。たとえば、MyServiceImplMyService インターフェイスを実装するクラスであると仮定すると、以下のように MyService OSGi サービスを公開できます。

    <?xml version="1.0" encoding="UTF-8"?>
    <blueprint xmlns="http://www.osgi.org/xmlns/blueprint/v1.0.0"
                xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
                default-activation="lazy">
    
      <bean id="myserviceimpl" class="org.example.MyServiceImpl"/>
    
      <service id="myservice" ref="myserviceimpl" interface="org.example.MyService"/>
    
    </blueprint>
  3. OSGi サービスに ACL を定義するには、org.apache.karaf.service.acl 接頭辞が付いた OSGi Config Admin PID を作成する必要があります。

    たとえば、Karaf コンテナーの場合 (OSGi Config Admin PID は etc/auth/ ディレクトリー下に .cfg ファイルとして格納される)、MyService OSGi サービスに以下の ACL ファイルを作成できます。

    etc/auth/org.apache.karaf.service.acl.myservice.cfg
    注記

    必要な接頭辞 org.apache.karaf.service.acl で始まる限り、このファイルの命名方法は重要ではありません。この ACL ファイルに対応する OSGi サービスは、実際にはこのファイルのプロパティー設定によって指定されます (次の手順で説明しています)。

  4. ACL ファイルのコンテンツを次のような形式で指定します。

    service.guard = (objectClass=InterfaceName)
    Pattern = Role1[,Role2][,Role3]...

    service.guard 設定は OSGi サービスの InterfaceName を指定します (LDAP 検索フィルターの構文を使用)。これは OSGi サービスプロパティーに適用されます。ACL ファイルの他のエントリーは、一致するメソッドを指定されたロールに関連付ける Pattern メソッドで設定されます。たとえば、org.apache.karaf.service.acl.myservice.cfg ファイルで以下の設定を使用して、MyService OSGi サービスの簡単な ACL を定義できます。

    service.guard = (objectClass=org.example.MyService)
    doit = admin, manager, viewer
  5. 最後に、この OSGi サービスの ACL を有効にするには、etc/system.properties ファイルの karaf.secured.services プロパティーを編集する必要があります。karaf.secured.services プロパティーの値は LDAP 検索フィルターの構文を持ちます (OSGi サービスプロパティーに適用される)。一般的に、OSGi サービス ServiceInterface の ACL を有効にするには、以下のようにこのプロパティーを変更する必要があります。

    karaf.secured.services=(|(objectClass=ServiceInterface)(...ExistingPropValue...))

    たとえば、MyService OSGi サービスを有効にするには、以下を行います。

    karaf.secured.services=(|(objectClass=org.example.MyService)(&(osgi.command.scope=*)(osgi.command.function=*)))

    karaf.secured.services プロパティーの初期値には、コマンドコンソール ACL を有効にする設定があります。これらのエントリーを削除または破損すると、コマンドコンソール ACL が機能しなくなる場合があります。

RBAC で保護された OSGi サービスを呼び出す方法

カスタム OSGi サービスでメソッドを呼び出す 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
  }
}
注記

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

Red Hat logoGithubRedditYoutubeTwitter

詳細情報

試用、購入および販売

コミュニティー

Red Hat ドキュメントについて

Red Hat をお使いのお客様が、信頼できるコンテンツが含まれている製品やサービスを活用することで、イノベーションを行い、目標を達成できるようにします。

多様性を受け入れるオープンソースの強化

Red Hat では、コード、ドキュメント、Web プロパティーにおける配慮に欠ける用語の置き換えに取り組んでいます。このような変更は、段階的に実施される予定です。詳細情報: Red Hat ブログ.

会社概要

Red Hat は、企業がコアとなるデータセンターからネットワークエッジに至るまで、各種プラットフォームや環境全体で作業を簡素化できるように、強化されたソリューションを提供しています。

© 2024 Red Hat, Inc.