3.8. Jakarta XML Web Services のセキュア化
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 またはアノテーションのいずれかを使用してこれらの要素を設定できます。
| 設定プロパティー | 説明 |
|---|---|
| ws-security.username |
|
| ws-security.password |
|
| ws-security.callback-handler |
キーストアおよび |
| ws-security.signature.properties | 署名キーストアと crypto オブジェクトを設定するための WSS4J プロパティーが含まれるプロパティーファイル/オブジェクト。 |
| ws-security.encryption.properties | 暗号キーストアおよび暗号化オブジェクトを設定するための WSS4J プロパティーが含まれるプロパティーファイル/オブジェクト。 |
| ws-security.signature.username | 使用される署名キーストアのキーのユーザー名またはエイリアス。指定されていない場合は、プロパティーファイルに設定されたデフォルトのエイリアスが使用されます。これが設定されておらず、キーストアに単一のキーのみが含まれる場合、そのキーが使用されます。 |
| ws-security.encryption.username |
使用される暗号キーストアのキーのユーザー名またはエイリアス。指定されていない場合は、プロパティーファイルに設定されたデフォルトのエイリアスが使用されます。これが設定されておらず、キーストアに単一のキーのみが含まれる場合、そのキーが使用されます。Web サービスプロバイダーの場合は、 |
| ws-security.signature.crypto |
これは、signature プロパティーを指定する代わりに、完全な WSS4J |
| ws-security.encryption.crypto |
これは、暗号化プロパティーを指定する代わりに、完全な WSS4J |
| 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 で宣言されます。
-
ws-requesterはws-providerに接続し、その WSDL を消費します。セキュリティートークンの発行者要件を見つけると、ws-requesterは、有効なリクエストを生成するために必要な情報を使用してSTSClientを作成し、設定します。 -
STSClientは STS に接続し、その WSDL を使用します。セキュリティーポリシーが検出されます。STSClientは、適切な認証情報を使用して認証リクエストを作成し、送信します。 - STS はクレデンシャルを検証します。
-
応答として、STS は
ws-requesterが STS で認証したことを証明するセキュリティートークンを発行します。 -
STSClientは、セキュリティートークンを含むメッセージをws-providerに提示します。 -
ws-providerは、トークンが STS によって発行されたことを確認し、ws-requesterが STS で正常に認証されたことを証明します。 -
ws-providerは要求されたサービスを実行し、結果をws-requesterに返します。
3.8.2.2. Apache CXF サポート リンクのコピーリンクがクリップボードにコピーされました!
Apache CXF はオープンソースの完全な Web サービスフレームワークです。JBossWS オープンソースプロジェクトは、JBoss Web Services (JBossWS) スタックと Apache CXF プロジェクトモジュールを統合し、WS-Trust およびその他の Jakarta XML Web Services 機能を提供します。この統合により、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.1. PicketLink WS-Trust Security Token Service (STS) の設定 リンクのコピーリンクがクリップボードにコピーされました!
Picketlink STS は、Apache CXF Security Token Service 実装の代替を構築するためのオプションを提供します。PicketLink を使用して、Web アプリケーションの SAML SSO を設定することもできます。PicketLink を使用した SAML SSO の設定に関する詳細は、How To Set Up SSO with SAML v2 を参照してください。
PicketLink WS-Trust STS として動作するようにアプリケーションを設定するには、以下の手順を実行する必要があります。
- WS-Trust STS アプリケーションのセキュリティードメインを作成します。
-
WS-Trust STS アプリケーションの
web.xmlファイルを設定します。 - WS-Trust STS アプリケーションの認証システムを設定します。
- WS-Trust STS アプリケーションに必要な依存関係を宣言します。
- WS-Trust STS アプリケーションの Web サービスの部分を設定します。
-
WS-Trust STS アプリケーションの
picketlink.xmlファイルを作成および設定します。
アプリケーションを作成およびデプロイする前に、セキュリティードメインを作成および設定する必要があります。
3.8.3.1.1. STS のセキュリティードメインの作成 リンクのコピーリンクがクリップボードにコピーされました!
STS は、提供された認証情報に基づいてプリンシパルの認証を処理し、その結果に基づいて適切なセキュリティートークンを発行します。これには、セキュリティードメインでアイデンティティーストアを設定する必要があります。このセキュリティードメインおよびアイデンティティーストアを作成する唯一の要件は、認証および承認メカニズムが適切に定義されていることです。これは、プロパティーファイル、データベース、LDAP など、さまざまなアイデンティティーストアを使用して STS アプリケーションをサポートすることができることを意味します。セキュリティードメインの詳細は、JBoss EAPSecurity Architecture のSecurity Domainsを参照してください。
以下の例では、アイデンティティーストアのプロパティーファイルを使用する簡単な UsersRoles ログインモジュールが使用されます。
セキュリティードメインを作成する CLI コマンド
/subsystem=security/security-domain=sts:add(cache-type=default)
/subsystem=security/security-domain=sts/authentication=classic:add
/subsystem=security/security-domain=sts/authentication=classic/login-module=UsersRoles:add(code=UsersRoles,flag=required,module-options=[usersProperties=${jboss.server.config.dir}/sts-users.properties,rolesProperties=${jboss.server.config.dir}/sts-roles.properties])
reload
結果の XML
<security-domain name="sts" cache-type="default">
<authentication>
<login-module code="UsersRoles" flag="required">
<module-option name="usersProperties" value="${jboss.server.config.dir}/sts-users.properties"/>
<module-option name="rolesProperties" value="${jboss.server.config.dir}/sts-roles.properties"/>
</login-module>
</authentication>
</security-domain>
ここで使用する管理 CLI コマンドは、JBoss EAP スタンドアロンサーバーを実行していることを仮定しています。JBoss EAP 管理対象ドメインの管理 CLI を使用する場合の詳細は 管理 CLI ガイド を参照してください。
プロパティーファイル
UsersRoles ログインモジュールは、プロパティーファイルを使用して、ユーザー/パスワードとユーザー/ロール情報を保存します。UsersRoles モジュールの詳細は、JBoss EAPLogin Module Reference を参照してください。この例では、プロパティーファイルには以下が含まれます。
例: sts-users.properties ファイル
Eric=samplePass
Alan=samplePass
例: sts-roles.properties ファイル
Eric=All
Alan=
また、セキュリティートークンの署名および暗号化のためにキーストアを作成する必要があります。このキーストアは、picketlink.xml ファイルを設定する際に使用されます。
3.8.3.1.2. STS の web.xml ファイルの設定 リンクのコピーリンクがクリップボードにコピーされました!
STS の web.xml ファイルには以下が含まれている必要があります。
-
STS 機能を有効化するための
<servlet>と、URL をマップするための<servlet-mapping>。 -
セキュアな領域の URL パターンにマップする
<url-pattern>が含まれる<web-resource-collection>を持つ<security-constraint>。任意で、<security-constraint>に許可されるロールを明記する<auth-constraint>を含めることもできます。 -
BASIC 認証に設定された
<login-config> -
<auth-constraint>にロールが指定されている場合、これらのロールを<security-role>で定義する必要があります。
例: web.xml ファイル
<web-app>
<!-- Define STS servlet -->
<servlet>
<servlet-name>STS-servlet</servlet-name>
<servlet-class>com.example.sts.PicketLinkSTService</servlet-class>
</servlet>
<servlet-mapping>
<servlet-name>STS-servlet</servlet-name>
<url-pattern>/*</url-pattern>
</servlet-mapping>
<!-- Define a security constraint that requires the All role to access resources -->
<security-constraint>
<web-resource-collection>
<web-resource-name>STS</web-resource-name>
<url-pattern>/*</url-pattern>
</web-resource-collection>
<auth-constraint>
<role-name>All</role-name>
</auth-constraint>
</security-constraint>
<!-- Define the Login Configuration for this Application -->
<login-config>
<auth-method>BASIC</auth-method>
<realm-name>STS Realm</realm-name>
</login-config>
<!-- Security roles referenced by this web application -->
<security-role>
<description>The role that is required to log in to the IDP Application</description>
<role-name>All</role-name>
</security-role>
</web-app>
3.8.3.1.3. STS の認証システムの設定 リンクのコピーリンクがクリップボードにコピーされました!
オーセンティケーターは、セキュリティートークンを発行および検証するユーザーの認証を行います。オーセンティケーターは、プリンシパルの認証および承認に使用されるセキュリティードメインを定義することで設定されます。
jboss-web.xml ファイルには以下が必要です。
-
認証または承認に使用されるセキュリティードメインを指定する
<security-domain>。
例: jboss-web.xml ファイル
<jboss-web>
<security-domain>sts</security-domain>
<context-root>SecureTokenService</context-root>
</jboss-web>
3.8.3.1.4. STS の必須依存関係を宣言します。 リンクのコピーリンクがクリップボードにコピーされました!
STS として機能する web アプリケーションは、org.picketlink クラスを見つけることができるように依存関係を jboss-deployment-structure.xml ファイルに定義する必要があります。JBoss EAP は必要なすべての org.picketlink と関連クラスを提供するため、アプリケーションはこれらの依存関係を宣言して使用することのみが必要となります。
例: jboss-deployment-structure.xml を使用した依存関係の宣言
<jboss-deployment-structure>
<deployment>
<dependencies>
<module name="org.picketlink"/>
</dependencies>
</deployment>
</jboss-deployment-structure>
3.8.3.1.5. STS の Web-Service ポートの設定 リンクのコピーリンクがクリップボードにコピーされました!
STS として機能する Web アプリケーションでは、クライアントがセキュリティートークンを取得するために呼び出すために web サービスを定義する必要があります。これには、PicketLinkSTS というサービス名と、PicketLinkSTSPort というポートを定義する必要があります。ただし、対象のデプロイメント環境をより効果的に反映するように SOAP アドレスを変更することができます。
例: PicketLinkSTS.wsdl ファイル
<?xml version="1.0"?>
<wsdl:definitions name="PicketLinkSTS" targetNamespace="urn:picketlink:identity-federation:sts"
xmlns:tns="urn:picketlink:identity-federation:sts"
xmlns:xsd="http://www.w3.org/2001/XMLSchema"
xmlns:wsdl="http://schemas.xmlsoap.org/wsdl/"
xmlns:wsap10="http://www.w3.org/2006/05/addressing/wsdl"
xmlns:soap12="http://schemas.xmlsoap.org/wsdl/soap12/">
<wsdl:types>
<xs:schema targetNamespace="urn:picketlink:identity-federation:sts"
xmlns:tns="urn:picketlink:identity-federation:sts"
xmlns:xs="http://www.w3.org/2001/XMLSchema"
version="1.0" elementFormDefault="qualified">
<xs:element name="MessageBody">
<xs:complexType>
<xs:sequence>
<xs:any minOccurs="0" maxOccurs="unbounded" namespace="##any"/>
</xs:sequence>
</xs:complexType>
</xs:element>
</xs:schema>
</wsdl:types>
<wsdl:message name="RequestSecurityToken">
<wsdl:part name="rstMessage" element="tns:MessageBody"/>
</wsdl:message>
<wsdl:message name="RequestSecurityTokenResponse">
<wsdl:part name="rstrMessage" element="tns:MessageBody"/>
</wsdl:message>
<wsdl:portType name="SecureTokenService">
<wsdl:operation name="IssueToken">
<wsdl:input wsap10:Action="http://docs.oasis-open.org/ws-sx/ws-trust/200512/RST/Issue" message="tns:RequestSecurityToken"/>
<wsdl:output wsap10:Action="http://docs.oasis-open.org/ws-sx/ws-trust/200512/RSTR/Issue" message="tns:RequestSecurityTokenResponse"/>
</wsdl:operation>
</wsdl:portType>
<wsdl:binding name="STSBinding" type="tns:SecureTokenService">
<soap12:binding transport="http://schemas.xmlsoap.org/soap/http"/>
<wsdl:operation name="IssueToken">
<soap12:operation soapAction="http://docs.oasis-open.org/ws-sx/ws-trust/200512/RST/Issue" style="document"/>
<wsdl:input>
<soap12:body use="literal"/>
</wsdl:input>
<wsdl:output>
<soap12:body use="literal"/>
</wsdl:output>
</wsdl:operation>
</wsdl:binding>
<wsdl:service name="PicketLinkSTS">
<wsdl:port name="PicketLinkSTSPort" binding="tns:STSBinding">
<soap12:address location="http://localhost:8080/SecureTokenService/PicketLinkSTS"/>
</wsdl:port>
</wsdl:service>
</wsdl:definitions>
さらに、web サービスが WSDL を使用するクラスが必要になります。
例: PicketLinkSTS クラス
@WebServiceProvider(serviceName = "PicketLinkSTS", portName = "PicketLinkSTSPort", targetNamespace = "urn:picketlink:identity-federation:sts", wsdlLocation = "WEB-INF/wsdl/PicketLinkSTS.wsdl")
@ServiceMode(value = Service.Mode.MESSAGE)
public class PicketLinkSTService extends PicketLinkSTS {
private static Logger log = Logger.getLogger(PicketLinkSTService.class.getName());
@Resource
public void setWSC(WebServiceContext wctx) {
log.debug("Setting WebServiceContext = " + wctx);
this.context = wctx;
}
}
3.8.3.1.6. STS の picketlink.xml ファイルの作成および設定 リンクのコピーリンクがクリップボードにコピーされました!
picketlink.xml ファイルは authenticator の動作を管理し、アプリケーションの起動時にロードされます。
JBoss EAP Security Token Service は、拡張ポイントを提供する複数のインターフェイスを定義します。実装はプラグイン処理でき、設定を使用してデフォルト値を一部のプロパティーに指定できます。How To Set Up SSO with SAML v2 の IDP および SP 設定と同様に、デプロイされたアプリケーションの picketlink.xml ファイルにすべての STS 設定が指定されます。以下は、picketlink.xml ファイルで設定できる要素です。
以下のテキストでは、サービスプロバイダーは、クライアントによるセキュリティートークンの提示を必要とする Web サービスを参照します。
<PicketLinkSTS>: これはルート要素です。STS 管理者が以下のプロパティーを設定できるようにするプロパティーを定義します。-
STSName: セキュリティートークンサービスの名前を表す文字列。指定されていない場合は、デフォルトのPicketLinkSTS値が使用されます。 -
TokenTimeout: トークンのライフタイム値 (秒単位)。指定されない場合は、デフォルト値の3600(時間) が使用されます。 -
EncryptToken: 発行されたトークンを暗号化するかどうかを指定するブール値。デフォルト値はfalseです。
-
-
<KeyProvider>: この要素と、そのサブ要素すべては、PicketLink STS がトークンに署名および暗号化するために使用するキーストアの設定に使用されます。このセクションでは、キーストアの場所、パスワード、署名 (秘密鍵) のエイリアス、パスワードなどのプロパティーをすべて設定します。 -
<TokenProviders>: このセクションは、各タイプのセキュリティートークンの処理に使用する必要があるTokenProvider実装を指定します。この例では、SAMLV1.1タイプのトークンを処理するプロバイダーと、SAMLV2.0タイプのトークンを処理するプロバイダーがあります。WSTrustRequestHandlerはSTSConfigurationのgetProviderForTokenType(String type)メソッドを呼び出し、適切なTokenProviderへの参照を取得します。 -
<ServiceProviders>: 本セクションでは、セキュリティートークンを必要とする web サービスである各サービスプロバイダーに使用する必要があるトークンタイプを指定します。WS-Trust リクエストにトークンタイプが含まれていない場合、WSTrustRequestHandlerはサービスプロバイダーのエンドポイントを使用して、発行する必要のあるトークンのタイプを特定する必要があります。
PicketLink を設定する場合は、セキュリティーが強化され、URL パラメーター内で応答が渡されないため、POST バインディングが推奨されます。
例: picketlink.xml 設定ファイル
<!DOCTYPE PicketLinkSTS>
<PicketLinkSTS xmlns="urn:picketlink:federation:config:2.1"
STSName="PicketLinkSTS" TokenTimeout="7200" EncryptToken="false">
<KeyProvider
ClassName="org.picketlink.identity.federation.core.impl.KeyStoreKeyManager">
<Auth Key="KeyStoreURL" Value="sts_keystore.jks"/>
<Auth Key="KeyStorePass" Value="testpass"/>
<Auth Key="SigningKeyAlias" Value="sts"/>
<Auth Key="SigningKeyPass" Value="keypass"/>
<ValidatingAlias Key="http://services.testcorp.org/provider1"
Value="service1"/>
</KeyProvider>
<TokenProviders>
<TokenProvider
ProviderClass="org.picketlink.identity.federation.core.wstrust.plugins.saml.SAML11TokenProvider"
TokenType="http://docs.oasis-open.org/wss/oasis-wss-saml-token-profile-1.1#SAMLV1.1"
TokenElement="Assertion" TokenElementNS="urn:oasis:names:tc:SAML:1.0:assertion"/>
<TokenProvider
ProviderClass="org.picketlink.identity.federation.core.wstrust.plugins.saml.SAML20TokenProvider"
TokenType="http://docs.oasis-open.org/wss/oasis-wss-saml-token-profile-1.1#SAMLV2.0"
TokenElement="Assertion" TokenElementNS="urn:oasis:names:tc:SAML:2.0:assertion"/>
</TokenProviders>
<ServiceProviders>
<ServiceProvider Endpoint="http://services.testcorp.org/provider1"
TokenType="http://docs.oasis-open.org/wss/oasis-wss-saml-token-profile-1.1#SAMLV2.0"
TruststoreAlias="service1"/>
</ServiceProviders>
</PicketLinkSTS>
デフォルトでは、picketlink.xml ファイルは STS Web アプリケーションの WEB-INF/classes ディレクトリーにあります。PicketLink 設定ファイルはファイルシステムから読み込むこともできます。PicketLink 設定ファイルをファイルシステムから読み込むには、picketlink-sts.xml という名前を付け、${user.home}/picketlink-store/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キー下で SOAPMessageContextに SAML2Assertionをプッシュできます。例を以下に示します。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. Jakarta Enterprise Beans サブシステムへの認証済みアイデンティティーの伝搬 リンクのコピーリンクがクリップボードにコピーされました!
webservices サブシステムには、アダプターが含まれます。これは、アノテーションまたはデプロイメント記述子のいずれかを使用して、Web サービスエンドポイントをセキュアにするために Elytron セキュリティードメインの設定することができます。
Elytron セキュリティーが有効になっている場合、JAAS サブジェクトまたはプリンシパルを Apache CXF エンドポイントの SecurityContext にプッシュし、認証済みアイデンティティーを Jakarta Enterprise Beans コンテナーに伝播できます。
以下は、Apache CXF インターセプターを使用して認証された情報を Jakarta Enterprise Beans コンテナーに伝播する方法の例になります。
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)
}
}