検索

3.8. JAX-WS Web サービスのセキュア化

download PDF

WS-Security は、HTTPS などのトランスポートレベルプロトコルを超えたサービスを保護する手段を提供します。WS-Security 標準で定義されたヘッダーなど、多くの標準を使用して以下を実行できます。

  • サービス間で認証トークンを渡します。
  • メッセージまたはメッセージの一部を暗号化する。
  • メッセージに署名します。
  • メッセージにタイムスタンプを付けます。

WS-Security は、公開鍵暗号および秘密鍵暗号を使用します。公開鍵暗号により、ユーザーは公開鍵と秘密鍵のペアを持ちます。これらは、高い素数とキー関数を使用して生成されます。

キーは関連するものですが、相互に派生させることはできません。これらの鍵を使用すると、メッセージを暗号化できます。たとえば、Scott が Adam にメッセージを送信する場合は、公開鍵を使用してメッセージを暗号化できます。次に、Adam は秘密鍵を使用してこのメッセージを復号化できます。秘密鍵のある唯一のメッセージであるため、このメッセージは Adam のみが復号化できます。

メッセージは署名することもできます。これにより、メッセージの信頼性を確保できます。Adam が Scott にメッセージを送信し、Scott が Adam からのメッセージであることを確認する必要がある場合、Adam は秘密鍵を使用してそのメッセージを署名できます。Scott は、公開鍵を使用して、メッセージが Adam からのものであることを検証できます。

3.8.1. Web Services Security (WS-Security) の適用

Web サービスは、WS-Security 機能が必要な多くの実際のシナリオをサポートします。これらのシナリオには、X509 証明書による署名および暗号化サポート、ユーザー名トークンによる認証および承認、および WS-SecurityPolicy 仕様でカバーされるすべての WS-Security 設定が含まれます。

その他の WS-* 機能については、WS-Security 機能のコアは Apache CXF エンジンを介して提供されます。さらに、JBossWS 統合では、WS-Security が有効なエンドポイントの設定を簡素化するいくつかの設定拡張が追加されました。

3.8.1.1. Apache CXF WS-Security 実装

Apache CXF は、複数の設定をサポートし、簡単に拡張できる WS-Security モジュールを特長としています。

システムは、低レベルのセキュリティー操作に対して Apache WSS4J に委譲するインターセプターに基づいています。インターセプターは、Spring 設定ファイルを使用するか、Apache CXF クライアント API を使用して直接設定できます。

Apache CXF の最近のバージョンでは、WS-SecurityPolicy のサポートが導入されました。WS-SecurityPolicy は、多くのセキュリティー設定をポリシーを介してサービスコントラクトに移動することを目的としています。これにより、クライアントがほぼ自動的に設定できるようになりました。これにより、ユーザーは必要なインターセプターの設定とインストールを手動で行う必要がなくなります。代わりに、Apache CXF WS-Policy エンジンがこれを行います。

3.8.1.2. WS-Security Policy のサポート

WS-SecurityPolicy は、特定の WSDL コントラクトで公開されるサービスとセキュアに通信するために必要なアクションを説明します。WSDL バインディングと操作は、WS-Policy フラグメントと、サービスと対話するためのセキュリティー要件を参照します。WS-SecurityPolicy 仕様は、暗号化にトランスポート (HTTPS) を使用して、暗号化に非対称および対称鍵などのものを指定できます。これは、暗号化または署名する部分またはヘッダー、その後に暗号化または署名するかどうか、タイムスタンプを含めるかどうか、派生キーを使用するかどうか、その他のキーを使用するかどうかなどを指定します。

ただし、一部の必須設定要素は公開されたエンドポイントコントラクトの一部やパブリックではなく、含まれるため、WS-SecurityPolicy では扱われません。これには、キーストアの場所、ユーザー名とパスワードなどが含まれます。Apache CXF では、Spring XML 記述子を使用するか、クライアント API またはアノテーションのいずれかを使用してこれらの要素を設定できます。

表3.4 サポートされる設定プロパティー
設定プロパティー説明

ws-security.username

UsernameToken ポリシーアサーションに使用するユーザー名。

ws-security.password

UsernameToken ポリシーアサーションに使用されるパスワード。指定されていない場合は、コールバックハンドラーが呼び出されます。

ws-security.callback-handler

キーストアおよび UsernameToken のパスワードを取得するために使用される WSS4J セキュリティー CallbackHandler

ws-security.signature.properties

署名キーストアと crypto オブジェクトを設定するための WSS4J プロパティーが含まれるプロパティーファイル/オブジェクト。

ws-security.encryption.properties

暗号キーストアおよび暗号化オブジェクトを設定するための WSS4J プロパティーが含まれるプロパティーファイル/オブジェクト。

ws-security.signature.username

使用される署名キーストアのキーのユーザー名またはエイリアス。指定されていない場合は、プロパティーファイルに設定されたデフォルトのエイリアスが使用されます。これが設定されておらず、キーストアに単一のキーのみが含まれる場合、そのキーが使用されます。

ws-security.encryption.username

使用される暗号キーストアのキーのユーザー名またはエイリアス。指定されていない場合は、プロパティーファイルに設定されたデフォルトのエイリアスが使用されます。これが設定されておらず、キーストアに単一のキーのみが含まれる場合、そのキーが使用されます。Web サービスプロバイダーの場合は、useReqSigCert キーワードを使用して、パブリックキーがサービスのトラストストアにあるクライアント (ws-security.encryption.properties で定義) を許可 (暗号化) できます。

ws-security.signature.crypto

これは、signature プロパティーを指定する代わりに、完全な WSS4J Crypto オブジェクトに向けることができます。これにより、暗号情報のプログラムによる設定が容易になります。

ws-security.encryption.crypto

これは、暗号化プロパティーを指定する代わりに、完全な WSS4J Crypto オブジェクトを参照します。これにより、暗号情報のプログラムによる設定が容易になります。

ws-security.enable.streaming

WS-Security メッセージのストリーミング (StAX ベースの) 処理を有効にします。

3.8.2. WS-Trust

WS-Trust は、WS-Security の拡張機能を定義する Web サービス仕様です。これは、分散システムにセキュリティーを実装するための一般的なフレームワークです。標準は、クライアントを認証し、さまざまなタイプの認証および承認データを含むトークンを発行できる集中型セキュリティートークンサービス (STS) に基づいています。この仕様は、セキュリティートークンの発行、交換、および検証に使用されるプロトコルを記述します。WS-Trust アーキテクチャーでは、以下の仕様が重要なロールを果たします。

  • WS-SecurityPolicy 1.2
  • SAML 2.0
  • ユーザー名トークンプロファイル
  • X.509 トークンプロファイル
  • SAML トークンプロファイル
  • Kerberos トークンプロファイル

WS-Trust 拡張機能は、複数のドメインにまたがり、セキュリティー鍵の共有を必要とするアプリケーションのニーズに対応します。これは、Web サービスプロバイダーと Web サービスプロバイダー間の信頼関係をブローカーするために、標準ベースの信頼できるサードパーティーの Web サービス (STS) を提供することで行います。このアーキテクチャーは、この情報の一般的な場所を提供することで、認証情報の変更を必要とするサービス更新の一時停止も軽減します。STS は、要求側とプロバイダーの両方がセキュリティートークンを取得し、検証する一般的なアクセスポイントです。

WS-Trust 仕様には、主に以下のコンポーネントがあります。

  • セキュリティートークンを発行、更新、および検証するためのセキュリティートークンサービス (STS)。
  • セキュリティートークン要求および応答のメッセージ形式。
  • 鍵交換のメカニズム。

次のセクションでは、基本的な WS-Trust シナリオについて説明します。高度なシナリオは、Advanced WS-Trust Scenarios を参照してください。

3.8.2.1. シナリオ: 基本的な WS-Trust

ここでは、基本的な WS-Trust シナリオの例を示します。これは、Web サービス要求側 (ws-requester)、Web サービスプロバイダー (ws-provider)、およびセキュリティートークンサービス (STS) で設定されます。

ws-provider では、非対称バインディングを使用して ws-requester によって提示される SAML 2.0 トークンが必要です。これらの通信要件は、ws-provider の WSDL で宣言されます。STS では、対称バインディングを使用して WSS UsernameToken 形式の要求に ws-requester 認証情報を提供する必要があります。STS からの応答には SAML 2.0 トークンが含まれています。これらの通信要件は、STS の WSDL で宣言されます。

  1. ws-requesterws-provider に接続し、その WSDL を消費します。セキュリティートークンの発行者要件を見つけると、ws-requester は、有効なリクエストを生成するために必要な情報を使用して STSClient を作成し、設定します。
  2. STSClient は STS に接続し、その WSDL を使用します。セキュリティーポリシーが検出されます。STSClient は、適切な認証情報を使用して認証リクエストを作成し、送信します。
  3. STS はクレデンシャルを検証します。
  4. 応答として、STS は ws-requester が STS で認証したことを証明するセキュリティートークンを発行します。
  5. STSClient は、セキュリティートークンを含むメッセージを ws-provider に提示します。
  6. ws-provider は、トークンが STS によって発行されたことを確認し、ws-requester が STS で正常に認証されたことを証明します。
  7. ws-provider は要求されたサービスを実行し、結果を ws-requester に返します。

3.8.2.2. Apache CXF サポート

Apache CXF はオープンソースの完全な Web サービスフレームワークです。JBossWS オープンソースプロジェクトは JBoss Web Services (JBossWS) スタックを Apache CXF プロジェクトモジュールと統合し、WS-Trust およびその他の JAX-WS 機能を提供します。この統合により、Apache CXF STS 実装のデプロイメントが容易になります。Apache CXF API は、Web サービスリクエスターとその STS との通信を容易にする STSClient ユーティリティーも提供します。

3.8.3. セキュリティートークンサービス (STS)

Security Token Service (STS) は WS-Trust 仕様の中核となります。認証および承認の標準ベースのメカニズムです。STS は、トークンの形式、名前空間、または信頼の境界に基づいて、セキュリティートークンの発行、変更、および検証を行うための WS-Trust 仕様のプロトコルの実装です。STS は、Web サービス要求側と Web サービスプロバイダーとの間の信頼関係をブローカー化するために信頼できるサードパーティーとして機能する Web サービスです。これは、要求側とプロバイダーの両方が信頼する共通のアクセスポイントで、相互運用可能なセキュリティートークンを提供します。これにより、要求元とプロバイダー間の直接的な関係が不要になります。STS は認証用の標準ベースのメカニズムであるため、レルム間および異なるプラットフォーム間での相互運用性を確保します。

STS コントラクトは、他のアプリケーションおよびプロセスが対話する方法を定義します。特に、WSDL は WS-Trust ポリシーと WS-Security ポリシーを定義します。このポリシーでは、リクエストャーが STS のエンドポイントと正常に通信するために満たさなければならなりません。Web サービスリクエスターは STS のパッケージを使用し、STSClient ユーティリティーを使用して、指定されたセキュリティーポリシーに準拠するメッセージリクエストを生成し、STS エンドポイントに送信します。STS は要求を検証し、適切な応答を返します。

3.8.3.2. クライアントでの WS-Trust Security Token Service (STS) の使用

STS からセキュリティートークンを取得するようにクライアントを設定するには、org.picketlink.identity.federation.api.wstrust.WSTrustClient クラスを利用して STS に接続し、トークンを発行するように要求する必要があります。

最初にクライアントをインスタンス化する必要があります。

例: WSTrustClient の作成

 WSTrustClient client = new WSTrustClient("PicketLinkSTS", "PicketLinkSTSPort",
       "http://localhost:8080/SecureTokenService/PicketLinkSTS",
       new SecurityInfo(username, password));

次に、WSTrustClient を使用して SAML アサーションなどのトークンが発行されるように要求する必要があります。

例: アサーションの取得

org.w3c.dom.Element assertion = null;
try {
   assertion = client.issueToken(SAMLUtil.SAML2_TOKEN_TYPE);
} catch (WSTrustException wse) {
   System.out.println("Unable to issue assertion: " + wse.getMessage());
   wse.printStackTrace();
}

アサーションを取得したら、そのアサーションを SOAP メッセージに追加および送信する方法があります。

  • クライアントは、org.picketlink.trust.saml.assertion キー下で SOAP MessageContext に SAML2 Assertion をプッシュできます。例を以下に示します。

    bindingProvider.getRequestContext().put(SAML2Constants.SAML2_ASSERTION_PROPERTY, assertion);
  • SAML2 Assertion は、セキュリティーコンテキストで JAAS サブジェクトの一部として利用できます。これは、PicketLink STS ログインモジュールと JAAS の対話がある場合に生じる可能性があります。

3.8.3.3. STS クライアントプール

警告

JBoss EAP では、STS クライアントプール機能はサポートされていません

STS クライアントプールは、サーバーに STS クライアントのプールを設定できるようにする機能であり、STS クライアント作成のボトルネックをなくすことができます。クライアントプールは、STS クライアントが SAML チケットを取得する必要があるログインモジュールに使用できます。これらの型には次のようなものがあります。

  • org.picketlink.identity.federation.core.wstrust.auth.STSIssuingLoginModule
  • org.picketlink.identity.federation.core.wstrust.auth.STSValidatingLoginModule
  • org.picketlink.trust.jbossws.jaas.JBWSTokenIssuingLoginModule

各ログインモジュールのプール内のクライアントのデフォルト数は、initialNumberOfClients ログインモジュールオプションを使用して設定されます。

org.picketlink.identity.federation.bindings.stspool.STSClientPoolFactory クラスはクライアントプール機能をアプリケーションに提供します。

STSClientPoolFactory の使用

STS クライアントは、STSClientConfig 設定をキーとして使用し 、サブプールに挿入されます。STS クライアントをサブプールに挿入するには、STSClientPool インスタンスを取得して、設定に基づいてサブプールを初期化する必要があります。オプションで、プールを初期化する際に STS クライアントの最初の数を指定することができます。または、デフォルトの数を使用することもできます。

例: STS クライアントのサブプールへの挿入

final STSClientPool pool = STSClientPoolFactory.getPoolInstance();
pool.createPool(20, stsClientConfig);
final STSClient client = pool.getClient(stsClientConfig);

クライアントでの作業が完了したら returnClient() メソッドを呼び出し、クライアントをプールに返すことができます。

例: STS クライアントのサブプールへの返信

pool.returnClient();

例: 任意の設定でサブプールが存在するかどうかの確認

if (! pool.configExists(stsClientConfig) {
    pool.createPool(stsClientConfig);
}

picketlink-federation サブシステムを有効にすると、デプロイメント用に作成されたすべてのクライアントプールがアンデプロイプロセス中に自動的に破棄されます。プールを手動で破棄するには、以下を実行します。

例: サブプールの手動破棄

pool.destroyPool(stsClientConfig);

3.8.4. 認証済みアイデンティティー の EJB サブシステムへの伝搬

webservices サブシステムには、アダプターが含まれます。これは、アノテーションまたはデプロイメント記述子のいずれかを使用して、Web サービスエンドポイントをセキュアにするために Elytron セキュリティードメインの設定することができます。

Elytron セキュリティーを有効にすると、JAAS サブジェクトまたはプリンシパルを Apache CXF エンドポイントの SecurityContext にプッシュし、認証されたアイデンティティーを EJB コンテナーに伝播できます。

以下は、Apache CXF インターセプターを使用して、認証された情報を EJB コンテナーに伝播する方法の例になります。

public class PropagateSecurityInterceptor extends WSS4JInInterceptor {
    public PropagateSecurityInterceptor() {
      super();
      getAfter().add(PolicyBasedWSS4JInInterceptor.class.getName());
   }
   @Override
   public void handleMessage(SoapMessage message) throws Fault {
      ...
      final Endpoint endpoint = message.getExchange().get(Endpoint.class);
      final SecurityDomainContext securityDomainContext = endpoint.getSecurityDomainContext();
      //push subject principal retrieved from CXF to ElytronSecurityDomainContext
      securityDomainContext.pushSubjectContext(subject, principal, null)
      }
    }
Red Hat logoGithubRedditYoutubeTwitter

詳細情報

試用、購入および販売

コミュニティー

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

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

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

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

会社概要

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

© 2024 Red Hat, Inc.