Menu Close

第1章 セキュリティーアーキテクチャー

概要

OSGi コンテナーでは、さまざまなセキュリティー機能をサポートするアプリケーションをデプロイすることができます。現時点で、Java Authentication and Authorization Service (JAAS) のみが共通のコンテナー全体のインフラストラクチャーに基づいています。その他のセキュリティー機能は、コンテナーにデプロイされる個々の製品およびコンポーネントによって個別に提供されます。

1.1. OSGi コンテナーセキュリティー

概要

図1.1「OSGi コンテナーセキュリティーアーキテクチャー」 は、コンテナー全体で使用され、コンテナーにデプロイされているすべてのバンドルからアクセスできるセキュリティーインフラストラクチャーの概要を表しています。この共通セキュリティーインフラストラクチャーは、現在すべてのアプリケーションバンドルで JAAS レルム (またはログインモジュール) を使用できるようにするためのメカニズムで構成されています。

図1.1 OSGi コンテナーセキュリティーアーキテクチャー

architecture 01

JAAS レルム

JAAS レルムまたはログインモジュールは、Java Authentication and Authorization Service (JAAS) 仕様で定義されているように、Java アプリケーションに認証および承認データを提供するプラグインモジュールです。

Red Hat Fuse は JAAS ログインモジュール (Spring または Blueprint ファイルのいずれか) を定義する特別なメカニズムをサポートします。これにより、ログインモジュールはコンテナーのすべてのバンドルからアクセスできます。これにより、OSGi コンテナーで実行している複数のアプリケーションが、セキュリティーデータを単一の JAAS レルムに統合できるようになります。

Karaf レルム

OSGi コンテナーには、事前定義された JAAS レルムである karaf レルムがあります。Red Hat Fuse は、karaf レルムを使用して、OSGi ランタイムのリモート管理、Fuse 管理コンソール、および JMX 管理の認証を提供します。karaf レルムは、認証データが InstallDir/etc/users.properties ファイルに保存される簡単なファイルベースのリポジトリーを使用します。

独自のアプリケーションで karaf レルムを使用できます。karaf を、使用する JAAS レルムの名前として設定するだけです。その後、アプリケーションは users.properties ファイルからのデータを使用して認証を実行します。

コンソールポート

Karaf クライアントでコンソールポートに接続するか、Karaf ssh:ssh コマンドを使用して、OSGi コンテナーをリモートで管理できます。コンソールポートは、karaf レルムに接続する JAAS ログイン機能によってセキュア化されます。コンソールポートへの接続を試みると、karaf レルムからアカウントのいずれかに一致する必要のあるユーザー名とパスワードの入力が要求されます。

JMX ポート

JMX ポートに接続すると、OSGi コンテナーを管理できます (Java の JConsole を使用するなど)。JMX ポートは、karaf レルムに接続する JAAS ログイン機能によっても保護されます。

アプリケーションバンドルと JAAS セキュリティー

OSGi コンテナーにデプロイするアプリケーションバンドルは、コンテナーの JAAS レルムにアクセスできます。アプリケーションバンドルは、既存の JAAS レルムのいずれかを名前 (JAAS ログインモジュールのインスタンスに対応) で参照するだけです。

ただし、JAAS レルムは OSGi コンテナー独自のログイン設定メカニズムを使用して定義することが不可欠です。デフォルトでは、Java は単純なファイルベースのログイン設定実装を提供しますが、OSGi コンテナーのコンテキストでこの実装を使用することはできません

1.2. Apache Camel のセキュリティー

概要

図1.2「Apache Camel のセキュリティーアーキテクチャー」 に、Apache Camel エンドポイント間でメッセージを安全にルーティングするための基本的なオプションの概要を示します。

図1.2 Apache Camel のセキュリティーアーキテクチャー

architecture 03

Apache Camel セキュリティーの代替

図1.2「Apache Camel のセキュリティーアーキテクチャー」 ので示すように、メッセージのセキュリティーを保護するためのオプションがあります。

  • エンドポイントセキュリティー - パート (a) は、セキュアなエンドポイントを持つ 2 つのルート間で送信されるメッセージを表しています。左側のプロデューサーエンドポイントは、右側のコンシューマーエンドポイントへのセキュアな接続 (通常は SSL/TLS を使用) を開きます。このシナリオでは、両方のエンドポイントがセキュリティーをサポートします。

    エンドポイントセキュリティーでは、通常、ピア認証 (場合によっては承認) の形式を実行できます。

  • ペイロードセキュリティー - パート (b) は、エンドポイントが両方とも安全でないルート間で送信されるメッセージを表しています。この場合、不正なスヌーピングからメッセージを保護するには、メッセージの送信前に暗号化し、受信後に復号化するペイロードプロセッサーを使用します。

    ペイロードセキュリティーの制限は、いかなる種類の認証または承認メカニズムも提供しないことです。

エンドポイントセキュリティー

セキュリティー機能をサポートする複数の Camel コンポーネントがあります。ただし、これらのセキュリティー機能は、Camel コアではなく、個々のコンポーネントによって実装されている点に留意することが重要です。したがって、サポートされるセキュリティー機能の種類や、実装の詳細はコンポーネントによって異なります。現在セキュリティーをサポートする Camel コンポーネントには、以下が含まれます。

  • JMS および ActiveMQ: クライアント対ブローカーおよびブローカー対ブローカーの通信用の SSL/TLS セキュリティーおよび JAAS セキュリティー。
  • Jetty: HTTP Basic Authentication および SSL/TLS セキュリティー。
  • CXF: SSL/TLS セキュリティーおよび WS-Security。
  • Crypto: メッセージの整合性を保証するために、デジタル署名を作成および検証します。
  • Netty: SSL/TLS セキュリティー。
  • MINA: SSL/TLS セキュリティー。
  • Cometd: SSL/TLS セキュリティー。
  • glogin および gauth: Google アプリケーションのコンテキストでの承認。

ペイロードセキュリティー

Apache Camel は、以下のペイロードセキュリティー実装を提供します。この実装では、暗号化手順および復号化手順は marshal() および unmarshal() 操作でデータ形式として公開されます。

XMLSecurity データフォーマット

XMLSecurity データフォーマットは、XML ペイロードを暗号化するために特別に設計されています。このデータフォーマットを使用する場合は、暗号化する XML 要素を指定することができます。デフォルトの動作では、すべての XML 要素を暗号化します。この機能は、対称暗号化アルゴリズムを使用します。

詳細は、http://camel.apache.org/xmlsecurity-dataformat.html を参照してください。

Crypto データフォーマット

crypto データフォーマットは、あらゆる種類のペイロードを暗号化できる汎用暗号化機能です。これは Java Cryptographic Extension をベースとしており、対称 (共有鍵) 暗号化と復号化のみを実装します。

詳細は、hhttp://camel.apache.org/crypto.html を参照してください。