| Oracle® Fusion Middleware Oracle SOAコア拡張機能開発者ガイド 12c (12.1.3) E54313-02 |
|
 前 |
 次 |
この章では、リモート通信のサービス・エンドポイントを保護する方法、およびソース・アプリケーションからAIAレイヤーを介してターゲット・アプリケーションに認証コンテキストを渡すために使用されるアプリケーション・セキュリティ・コンテキストを保護する方法を説明します。
この章の内容は次のとおりです。
デフォルトでは、Oracle AIAのすべてのサービスが保護されます。アダプタ・ベースのすべてのサービスは、JNDIを使用してセキュリティが有効化されます。SOAP over HTTPを使用するすべてのコンポジット・サービスと参照は、Oracle Web Services Manager (WSM)を使用して保護されます。
提供されたセキュリティが自社のユースケースに十分でない場合は、セキュリティをオーバーライドできます。
サービス間相互作用の保護では、次のことを実行します。
認証によってクライアントを識別します。
暗号化によってメッセージを保護します。
デジタル署名を使用してメッセージの改ざんを防止します。
SSLを使用してチャネルを暗号化します。
図19-1に、AIAの高度なセキュリティ構造を示します。
図19-1 高度なセキュリティ・アーキテクチャ
Oracle WSMを使用してWebサービス・セキュリティをOracle AIAに構成することをお薦めします。AIAサービスに対するセキュリティを有効にするには、Oracle WSMを使用して適切なサービス・ポリシーを割り当てます。保護されたサービスをコールするには、適切なクライアント側ポリシーを割り当てます。
サービスの保護に関するAIAの推奨事項は次のとおりです。
すべてのWebサービスを保護してください。これには、次のものが含まれます。
アプリケーション・ビジネス・コネクタ・サービス(ABCS)、エンタープライズ・ビジネス・サービス(EBS)、トランスポート・アダプタ・サービスなどのAIAサービス。
Oracle Fusion Middlewareでホストされているその他のアプリケーション・サービス。
標準のインストールでは、セキュリティ・ポリシーが適用されたサービスをデプロイしてください。
このリリースでは、AIAサービスが提供する最低限の保護は認証です。
本番環境では、メッセージ保護を使用してサービスを強化してください。
Oracle Web Services Manager (WSM)のセキュリティと管理は、Oracle WebLogic Serverに統合されています。
Oracle Web Services Managerの詳細は、『Webサービスの管理』を参照してください
デプロイメント時にOracle WSMを使用してWebサービス・セキュリティを宣言して構成することによって、セキュリティ・ロジックをサービス開発から分離することをお薦めします。やむを得ない理由(参加アプリケーションがWebサービス・セキュリティをサポートしていないなど)がないかぎり、SSLではなくWebサービス・セキュリティを使用してください。
AIAでは、SOA Suiteの一部としてOracle WSMがインストールされ、最もよく使用されるセキュリティのユースケースに対するポリシーが提供されます。Oracle WSMには、特別なセキュリティ機能をスタンドアロンで追加したり、他のセキュリティ機能と組み合せて追加するためのポリシーがあります。
ポリシーは、次のような様々な粒度でサービスに対してグローバルにアタッチされます。
ドメイン - ドメイン内のすべてのサービス
インスタンス - WLSサーバー・インスタンス内のすべてのサービス
SOAコンポジット名ベース - コンポジット内のすべてのサービス
提供されるポリシーのリストは、『Webサービスの管理』の事前定義済ポリシーに関する項を参照してください
この項には次のトピックが含まれます:
AIAサービスのセキュリティを有効にする手順は、次のとおりです。
必要なセキュリティのタイプを判断します。
認証、暗号化および整合性にはWS-securityの使用をお薦めします。
グローバル・セキュリティ・ポリシーがWebサービスに十分かどうかをチェックします。
適切な機能の組合せを含むWS-policyを検索します。
たとえば、暗号化と整合性が必要な場合は、暗号化と整合性の両方を処理するポリシーを検索する必要があります。
ポリシーをサービスにアタッチして、サービスに対するセキュリティを有効にします。
ポリシーのアタッチ方法の詳細は、『Webサービスの管理』の、Webサービスへのポリシーのアタッチに関する項を参照してください。
ポリシーを構成します。
各ポリシーに対して追加の構成を実行できます。
各ポリシーを構成する方法の詳細は、『Webサービスの管理』の、のポリシーの構成に関する項を参照してください。
問題を診断します。
問題の診断方法の詳細は、『Webサービスの管理』の問題の診断に関する項を参照してください。
セキュリティは、パフォーマンスにマイナスの影響を与える場合があるため、慎重に使用する必要があります。AIAでは、組織の境界を越えて他のサービスと相互作用するサービスの保護が必須です。企業ネットワーク外部のクライアントからコールされるすべてのAIAサービスを保護する必要があります。すべてのサービスが同じ組織内かつファイアウォールの内側に存在するA2A統合では、必ずしもすべてのサービスを保護する必要はないと判断できます。
初期状態のすべてのAIAサービスが保護されていて、自社のデプロイメントにセキュリティが必要ないと考えられる場合は、セキュリティを無効にしてください。
保護されたアプリケーション・サービスを呼び出す手順は、次のとおりです。
必要なセキュリティのタイプを判断します。
認証、暗号化および整合性にはWS-securityの使用をお薦めします。
グローバル・セキュリティ・ポリシーがWebサービスに十分かどうかをチェックします。
適切な機能の組合せを含むWS-policyを検索します。
たとえば、暗号化と整合性が必要な場合は、暗号化と整合性の両方を処理するポリシーを検索する必要があります。
ポリシーをサービスにアタッチして、サービスに対するセキュリティを有効にします。
ポリシーのアタッチ方法の詳細は、『Webサービスの管理』の、Webサービスへのポリシーのアタッチに関する項を参照してください。
ポリシーを構成します。
各ポリシーに対して追加の構成を実行できます。
WS-Securityのクライアント側の基本認証ポリシーの場合は、次の操作を実行する必要があります。
資格証明ストアを構成します。
キーに関連するユーザーIDとパスワードをストアに追加します。
ポリシーでキーを使用します。
各ポリシーを構成する方法の詳細は、『Webサービスの管理』の、のポリシーの構成に関する項を参照してください。
問題を診断します。
問題の診断方法の詳細は、『Webサービスの管理』の問題の診断に関する項を参照してください。
SOAコア拡張機能には、グローバル・ポリシーを宣言でオーバーライドするインフラストラクチャがあります。ポリシーをオーバーライドするには、サービス開発者が次の操作を実行する必要があります。
「AIAセキュリティ構成プロパティ」の項で説明されているように、サービス構成ファイルを作成します。
これをプロジェクト・フォルダに配置します。
CAVSを使用して保護されたサービスをテストするには、要素<cavs:CAVSRequestInput_1>に、例19-1の<soap:Envelope>の下に示した要素が設定されている必要があります。
アイデンティティ・ストアのデフォルト・ユーザーを使用している場合、[user name] = weblogic、[pwd] = weblogic#1です。
例19-1 <soap:Envelop>のコンテンツ
<soapenv:Header>
<wsse:Security
xmlns="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-
secext-1.0.xsd"
xmlns:wsse="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-
secext-1.0.xsd">
<wsse:UsernameToken>
<Username>[user name]</Username>
<Password>[pwd]</Password>
</wsse:UsernameToken>
</wsse:Security>
</soapenv:Header>
この項では、次の項目について説明します。
参加アプリケーションの組込み機能を使用して、サービスのセキュリティを有効にできます。セキュリティを有効にする製品を選択するには、そのアプリケーションに対するエージェント・サポートがOracle WSMにあるかどうかをチェックし、ある場合はOracle WSMを使用します。
アプリケーションで任意の種類のセキュリティが使用可能な場合は、認証、暗号化および整合性についてWebサービス・セキュリティを使用します。それ以外の場合は、SSLを使用して接続を保護できます。
WS-securityに対して有効化されたAIAサービスと相互作用する場合は、AIAサービスのセキュリティ機能に必要なすべての情報をSOAPヘッダーのセキュリティ・ヘッダーに追加する必要があります。AIAサービスのセキュリティに基づいて、認証、暗号化および整合性のいずれかの組合せについて情報を追加する必要があります。
例19-2は、認証用のセキュリティ・ヘッダーのサンプルです。
AIAサービスにSSLが必要な場合は、一方向および双方向SSLの両方についてアプリケーションでSSLを構成する必要があります。
例19-2 認証用のセキュリティ・ヘッダー
<wsse:Security env:mustUnderstand="1">
<wsse:UsernameToken wsu:Id="UsernameToken-dXtD14011QZUTlfIaSrMhw22">
<wsse:Username>weblogic</wsse:Username>
<wsse:Password
Type="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-username-token-
profile-1.0#PasswordText">weblogic1</wsse:Password>
</wsse:UsernameToken>
</wsse:Security>
ポリシーは、個別のサービス・レベルで制約したポリシー・アタッチメントではなく、グローバルに適用することをお薦めします。SOAコア拡張機能のインストール時には、グローバル・ポリシーが適用されています。
グローバルにアタッチされたクライアント・ポリシーを直接アタッチされたローカル・ポリシーでオーバーライドすることが避けられない場合があります。一般的なガイドラインは次のとおりです。
グローバル認証ポリシーが提供されます。
ポリシーをコンポジット・レベルで定義する必要がなくなります。
適用済のグローバル・サービス・ポリシー: oracle/aia_wss_saml_or_username_token_service_policy_OPT_ON
これは、ローカル最適化がオンに設定されたoracle/wss_saml_or_username_token_service_policyのクローン・コピーです。
適用済のグローバル・サービス・クライアント・ポリシー: oracle/aia_wss10_saml_token_client_policy_OPT_ON
これは、ローカル最適化がオンに設定されたoracle/wss10_saml_token_client_policyのクローン・コピーです。
自社の個別フロー・ニーズを評価し、必要な場合はサービスを強化します。
さらに強化を行うには、ローカル・ポリシーを関連付けます。
保護されたAIA Webサービスを呼び出すアプリケーションは、資格証明を送信する必要があります。
AIA間の通信は、グローバル・サービス・クライアント・ポリシーによって処理されます。
通常は、自社組織のセキュリティ・ポリシーの基本的な要件に基づいて、使用するポリシーを決定します。次の質問は、使用可能なポリシーを判断するのに役立ちます。
ユーザーの認証のみが必要ですか。
メッセージの保護が必要ですか。
トランスポート・レイヤーとSOAPヘッダーのどちらにトークンを組み込みますか。
特定タイプのトークンを使用する必要がありますか。
次のポリシーをAIAサービスにグローバルにアタッチする必要があります。
oracle/aia_wss_saml_or_username_token_service_policy_OPT_ON
aia_wss_saml_or_username_or_http_token_service_policy_OPT_ON
oracle/aia_wss10_saml_token_client_policy_OPT_ON
oracle/aia_wss_saml_or_username_token_service_policy_OPT_ON
これは、ローカル最適化がオンに設定されたoracle/wss_saml_or_username_token_service_policyのクローン・コピーです。クライアントとサービス・コンポジットが同一の場所に配置されている場合は、ローカル最適化を使用する必要があります。
このポリシーは、WS-Security SOAPヘッダーのSAMLトークンまたはUsernameToken WS-Security SOAPヘッダーに含まれる資格証明を使用してユーザーを認証します。SAMLトークンの資格証明はSAMLログイン・モジュールに対して認証される一方、UsernameTokenの資格証明は構成済のアイデンティティ・ストアに対して認証されます。UsernameTokenにはプレーン・テキスト・メカニズムのみがサポートされています。このポリシーは、どのようなSOAPベースのエンドポイントにも適用できます。
aia_wss_saml_or_username_or_http_token_service_policy_OPT_ON
これは、ローカル最適化がオンに設定され、HTTP基本認証が追加オプションとして追加されたoracle/wss_saml_or_username_token_service_policyのクローン・コピーです。Webサービス・セキュリティを使用するためのインフラストラクチャがないODIなどのクライアントは、HTTP基本認証を使用してサービスをコールできます。
これはAIAAsyncErrorHandlerBPELサービスのみにアタッチされます。
oracle/aia_wss10_saml_token_client_policy_OPT_ON
これは、ローカル最適化がオンに設定されたoracle/wss10_saml_token_client_policyのクローン・コピーです。クライアントとサービス・コンポジットが同一の場所に配置されている場合は、ローカル最適化を使用する必要があります。
このポリシーには、アウトバウンドSOAPリクエスト・メッセージのSAMLトークンが含まれます。
この項には次のトピックが含まれます:
サービス固有のグローバル・ポリシー・セットの命名規則
AIA_[ServiceType]_WSServicePolicySet
サービス・タイプの可能な値は次のとおりです。
ABCS
EBS
EBF
Adapter
Producer
Consumer
例: AIA_ABCS_WSServicePolicySet
クライアント固有のグローバル・ポリシー・セットの命名規則
AIA_[ServiceType]_WSClientPolicySet
サービス・タイプの可能な値は次のとおりです。
ABCS
EBS
EBF
Adapter
Producer
Consumer
例: AIA_ABCS_WSClientPolicySet
SOAコア拡張機能では、次の処理が自動的に実行されます。
推奨グローバル・ポリシー・セットが作成されます。
必要な場合はコンポジットに対するローカル・ポリシーがアタッチされます。
この項には次のトピックが含まれます:
グローバル・ポリシーのデプロイメントは、SOAコア拡張機能のインストール時に処理されます。グローバル・サービスとクライアント・ポリシーのセットがSOAコア拡張機能のインストール時にWLSドメインにアタッチされます。結果として、そのサーバーにデプロイされる(パターンが一致する)すべてのサービスが自動的に保護されます。
SOAコア拡張機能のインストーラでは、コンポジット名のパターンに対して、サービス固有とクライアント固有の両方のグローバル・ポリシー・セットが作成されます。
ABCS
EBS
EBF
Adapter
Producer
Consumer
SOAコア拡張機能のインストーラでは、次のポリシー・セットが作成されます。
コンポジット・サービスにアタッチされるグローバルPolicySet
AIA_ABCS_WSServicePolicySet
AIA_EBS_WSServicePolicySet
AIA_EBF_WSServicePolicySet
AIA_Adapter_WSServicePolicySet
AIA_Consumer_WSServicePolicySet
AIA_Producer_WSServicePolicySet
コンポジット参照にアタッチされるグローバルPolicySet
AIA_ABCS_WSClientPolicySet
AIA_EBS_WSClientPolicySet
AIA_EBF_WSClientPolicySet
AIA_Adapter_WSClientPolicySet
AIA_Consumer_WSClientPolicySet
AIA_Producer_WSClientPolicySet
異なるセキュリティ・ポリシーを必要とする保護されたアプリケーション・サービスと相互作用するコンポジットにはローカル・ポリシーがアタッチされ、デプロイメント時にグローバル・ポリシーがオーバーライドされます。
同様に、保護されていないアプリケーション・サービスと相互作用する必要があるコンポジットにはNoClientAuthenticationPolicyがアタッチされ、グローバル・ポリシー・セットがオーバーライドされます。
AIAデプロイメント・ドライバでは通常、オーバーライド・ローカル・セキュリティ・ポリシーのアタッチがサポートされますが、サポートされるのは、saml-tokenおよびusername-tokenクライアント・ポリシーに対する構成オーバーライドのみです。
異なるクライアント(ローカル)ポリシーを使用すると、AIAデプロイメント・ドライバによってポリシーがアタッチされますが、その構成は手動タスクとなります。
例19-3は、XMLファイルの構造を示しています。
サービス・エンドポイントまたは参照エンドポイント(あるいはその両方)にアタッチされたローカル・ポリシーを必要とするコンポジットは、SOAコア拡張機能ツールに情報を提供する必要があります。これらのコンポジットには、xmlベースのセキュリティ構成ファイルが関連付けられている必要があります。このファイルの名前は、AIASecurityConfigurationProperties.xmlです。
SOAコア拡張機能ツールでは、次の情報が必要です。
コンポジットの名前
ローカル・ポリシーを必要とするすべてのサービス・エンドポイントの名前
ローカル・ポリシーを必要とするすべての参照エンドポイントの名前
ローカルにアタッチする必要があるポリシーの名前
ローカル・ポリシー・アタッチメントを必要とするコンポジットに関連付けられたAIASecurityConfigurationProperties.xmlによって、前述の情報を提供する必要があります。このファイルは、プロジェクト・アーティファクトとともにcomposite.xmlと同じフォルダに配置されます。
このファイルはソースで制御されます。
コンポジットにローカル・ポリシー・アタッチメントが必要ない場合、そのコンポジットに対するxmlファイルを定義は不要です。
例19-3に、サンプルのAIASecurityConfigurationProperties.xmlを示します。
ヒント:
composite.xml内のreference要素のbinding.wsで、port属性には次のフォームの値を指定します。
<binding.ws port="[wsdlに定義されているサービスのネームスペース]/V1#wsdl.endpoint(<サービス>/<ポート>"
ここで指定したPortNameがcomposite.xmlの<ポート>と同じであることを確認してください。
コンポジットに関する注意点は次のとおりです。
サービス・エンドポイントに直接ポリシー・アタッチメントは必要ないが、参照エンドポイントには必要な場合、AIASecurityConfigurationProperties.xmlにservice要素を設定する必要はありません。
参照エンドポイントに直接ポリシー・アタッチメントは必要ないが、サービス・エンドポイントには必要な場合、AIASecurityConfigurationProperties.xmlにreference要素を設定する必要はありません。
複数のサービス・エンドポイントがあり、その1つのみにポリシーを直接アタッチする必要がある場合、AIASecurityConfigurationProperties.xmlに存在する必要があるのは1つのservice要素のみです。
複数の参照エンドポイントがあり、その1つのみにポリシーを直接アタッチする必要がある場合、AIASecurityConfigurationProperties.xmlに存在する必要があるのは1つのreference要素のみです。
例19-3 AIASecurityConfigurationProperties.xmlのサンプル
<?xml version="1.0" encoding="UTF-8"?>
<!--Note: the attribute 'compositeName' is the name of the AIA Service
composite preprended by {namespace of the AIA service as defined
in its wsdl} -->
<SecurityConfiguration xmlns="http://xmlns.oracle.com/fp/core/security/V1"
version="1.0"
compositeName="{http://xmlns.oracle.com/ABCSImpl/Siebel/Samples/
SamplesCreateCustomerSiebelReqABCSImpl/V1}SamplesCreateCustomerSiebel
ReqABCSImpl">
<!-- the following element is repeated for each service end point of this
Composite ,which requires a direct (local) policy attachement -->
<Service resourceType='SOA-Service' >
<!-- It is the service endpoint. It should be same as attribute 'name' of
element 'service' in composite.xml -->
<Name>SamplesCreateCustomerSiebelReqABCSImpl</Name>
<!-- This is the port name. For BPEL-based references, its value is Name of the
Porttype as given in the WSDL of this AIA service
For Mediator-based reference, this is [Name of the Porttype element as given in
the WSDL]_pt This example assumes a scenario when services and wsdls are coded
by following the AIA naming conventions.In other scenarios, the value might be
slightly different. Look at the hint below to come up with the correct value
for the element PortName.-->
<PortName>SamplesCreateCustomerSiebelReqABCSImpl</PortName>
<WSPolicies>
<WSPolicyName policyType ="authentication">oracle/wss_username_token_service_
policy</WSPolicyName>
</WSPolicies>
</Service>
<!-- the following element is repeated for each reference end point of this
Composite ,which requires a direct (local) policy attachement -->
<Reference resourceType = 'SOA-Reference'>
<!-- should be same as attribute 'name' of element 'reference' in
composite.xml -->
<Name>SamplesCustomerPartyEBS</Name>
<!-- port name.
For BPEL-based references, its value is name of the Porttype element as given
in the WSDL of this AIA service.
For Mediator-based reference, the value is [Name ofthe Porttype element as
given in the WSDL]_pt
-->
"This example assumes a scenario when services and wsdls are coded by following
the AIA naming conventions. In other scenarios, the value might be slightly
different. Look at the hint below to come up with the correct value for the
element PortName. Hint: In the composite.xml, for the binding.ws of the
'service' element, the attribute 'port' takes value of the following form.
<binding.ws port="[namespace of the service as defined in the
wsdl]/V1#wsdl.endpoint(<Service>/<Port>" Make sure that the PortName provided
by you here, is same as <Port> in the composite.xml"
<PortName>CustomerPartyEBS_pt</PortName>
<WSPolicies>
<WSPolicyName policyType ="authentication">oracle/wss_username_token_client_
policy</WSPolicyName>
<ConfigParams>
<!-- Param could be a repeating element- Future use only -->
<!-- APPSHORTNAME should be same as application's short name -->
<!-- ServiceName and PortTypeName are as given in the APP's web service WSDL
-->
<Param paramName="csf-key">APPSHORTNAME_ServiceName_PortTypeName</Param>
</ConfigParams>
</WSPolicies>
</Reference>
</SecurityConfiguration>
この項には次のトピックが含まれます:
Oracle AIAアプリケーション・セキュリティ・モデルを使用すると、AIAではポイントツーポイント・セキュリティを排除することによって、セキュリティ表現が異なる複数の参加アプリケーションを標準的な方法で統合できます。
各参加アプリケーションは、異なる時期に、異なるコンセプト、異なる認証および認可の実装を使用して開発されています。アプリケーションが統合される場合は、アプリケーション間で認証および認可情報を渡す必要があります。AIAアプリケーション・セキュリティ・コンテキストは、任意のアプリケーションを他のアプリケーションと統合できるように、様々な参加アプリケーション間でのアプリケーションの認証および認可情報の交換を標準化します。
図19-2に、高度なセキュリティ機能フローを示します。
図19-2 セキュリティ機能フロー
アプリケーション・コンテキストは、メッセージを処理するためにリクエスタ・アプリケーションとプロバイダ・アプリケーション間で送信する必要がある情報です。これには、認証および認可情報なども含まれます。AIAでは認可情報の交換がアプリケーション・コンテキストで処理されますが、設計では他のコンテキスト情報の追加がサポートされています。
AIAでは、XACMLコンテキスト・リクエストが認可情報を表現する最適な標準であると判断されました。XACMLは、アクセス制御ポリシーを管理するためのOASIS標準です。XACMLはXMLをベースとして2003年にリリースされ、アクセス権のあるユーザーとアクセスできるリソースを記述するための共通の標準になるように設計されています。XACMLには、許可、拒否、中間(問合せのエラー)または適用不可のレスポンスを生成するポリシー言語と問合せ言語が含まれています。問合せ言語は、認可情報の交換のためにAIAが推奨するXACMLコンテキストで表現されます。
優先アプローチは、リクエスタ・アプリケーションがコンテキスト情報をXACMLリクエストとしてリクエスタABCSに送信することです。コンテキスト情報をXACMLリクエストに編成する機能がアプリケーションにない場合、参加アプリケーションはアプリケーション・コンテキスト情報をSOAPヘッダーで、またはビジネス・メッセージ・コンテンツの一部として送信します。
参加アプリケーションでSOAPインタフェースが使用されていない場合は、プロトコル固有アダプタの使用をお薦めします。このシナリオでは、アダプタがアプリケーション・コンテキストをカスタムの方法で受信し、参加アプリケーション固有のXACMLリクエストを準備してABCSに送信します。
図19-3に、リクエスタ・アプリケーション・フローを示します。
図19-3 リクエスタ・アプリケーション・フロー
優先アプローチは、プロバイダABCSがアプリケーション・コンテキストをXACMLリクエストとしてプロバイダ・アプリケーションに送信することです。プロバイダ・アプリケーションではXACMLリクエストを受信できないが、SOAPインタフェースがある場合、プロバイダABCSはアプリケーション・セキュリティ・コンテキストをSOAPヘッダーのカスタムXML形式で、またはビジネス・ドキュメントの一部として送信します。プロバイダ・アプリケーションでSOAPインタフェースがサポートされていない場合、プロバイダABCSはアプリケーション・コンテキストをXACMLリクエストの形式でアダプタ・サービスに送信し、アダプタ・サービスが、使用中のセキュリティ・メカニズムに必要な適切なセキュリティ・コンテキストを設定します。
図19-4に、プロバイダ・アプリケーション・フローを示します。
図19-4 プロバイダ・アプリケーション・フロー
リクエスタABCSは、アプリケーション・セキュリティ・コンテキストをXACML形式で受信するか、またはXACML形式に変換します。リクエスタABCSは外部サービスをコールして、アプリケーション・セキュリティ・コンテキストを標準セキュリティ・コンテキストにマップします。ABCSは、アプリケーション・セキュリティ・コンテキストをXACML形式で渡し、アプリケーション・ニュートラル・セキュリティ・コンテキストをXACML形式で受信します。
アプリケーションごとに1つの外部サービスの使用をお薦めします。このサービスは、返される標準またはアプリケーション・コンテキストに必要な追加の値も入力します。このサービスは、XPath関数または次の名前のWebサービスとして実装できます。
Request TransformToAppContext (EBMHeader)
Request TransformToAppNeutralContext (Request)
例19-4に、サンプルのAppContextMappingServiceを示します。
このサービスは参加アプリケーションに対して実装され、そのアプリケーションを使用したすべての統合シナリオに対応します。
このサービスを実装するには、同一の場所に配置されたBPELの使用をお薦めします。ABCSでは、このサービスの他の実装をプラグインできるように、動的パートナ・リンクを使用してこのサービスをコールする必要があります。
TransformAppContextServiceは、サービス実装をAIAConfigプロパティ・ファイルからロードする際に使用するプロパティです。デフォルトでは、このプロパティは構成されておらず、デフォルトの実装が使用されます。
このサービスのデフォルトの実装は、DVMおよび相互参照に基づいています。新しいアプリケーションまたは統合シナリオを追加する場合は、DVMの値を必ず入力する必要がありますが、サービスの変更は不要です。
例19-4 AppContextマッピング・サービスの例
<definitions
targetNamespace="http://www.oracle.com/AIA/AppContextTransformService"
xmlns:corecom="http://xmlns.oracle.com/EnterpriseObjects/Core/Common/V2"
xmlns:xacml-context="http://docs.oasis-open.org/xacml/access_
control-xacml-2.0-context-schema-cd-04.xsd"
xmlns="http://schemas.xmlsoap.org/wsdl/"
xmlns:tacs="http://www.oracle.com/AIA/AppContextTransformService"
xmlns:mime="http://schemas.xmlsoap.org/wsdl/mime/"
xmlns:xsd="http://www.w3.org/2001/XMLSchema"
xmlns:soap="http://schemas.xmlsoap.org/wsdl/soap/">
<types>
<xsd:schema
targetNamespace="http://www.oracle.com/AIA/AppContextTransformService"
elementFormDefault="qualified">
<xsd:import namespace="http://docs.oasis-open.org/xacml/access_
control-xacml-2.0-context-schema-cd-04.xsd"
schemaLocation="http://[HOST:PORT]/AIAComponents/EnterpriseObjectLibrary/Release2
/Core/Common/V2/access_control-xacml-2.0-context-schema-cd-04.xsd" />
<xsd:import namespace="http://xmlns.oracle.com/EnterpriseObjects/Core/Common/V2"
schemaLocation="http://[HOST:PORT]/AIAComponents/EnterpriseObjectLibrary/Release2
/Core/Common/V2/Meta.xsd" />
</xsd:schema>
</types>
<message name="Request">
<part name="Request" element="xacml-context:Request"/>
</message>
<message name="EBMHeader">
<part name="EBMHeader" element="corecom:EBMHeader"/>
</message>
<portType name="TransformAppContext">
<operation name="TransformToAppContext">
<input message="EBMHeader" name="EBMHeader"/>
<output message="Request"/>
</operation>
<operation name="TransformToAppNeutralContext">
<input message="Request" name="Request"/>
<output message="Request"/>
</operation>
</portType>
</definitions>
XACMLリクエスト要素は、アプリケーション・コンテキスト構造に対するパラメータとして使用されます。このリクエスト要素には、認可情報に加えて、参加アプリケーション情報とコール側サービス情報が保持されます。
図19-5に、XACMLリクエストの構造を示します。
図19-5 XACMLリクエストの構造
図19-6に、XACMLサブジェクトの構造を示します。
図19-6 XACMLサブジェクトの構造
図19-7に、XACMLリソースの構造を示します。
図19-7 XACMLリソースの構造
図19-8に、XACMLアクションの構造を示します。
図19-8 XACMLアクションの構造
図19-9に、XACML環境の構造を示します。
図19-9 XACML環境の構造
例19-5に、セキュリティ・サービスに送信されるSEBL AppContext情報を示します。
例19-5 セキュリティ・サービスに送信されるSEBL AppContext情報の例
<AIAAppContext xmlns=http://www.oracle.com/AIA/AppContext>
<ServiceInfo>
<ServiceName>O2C2SeibelABCS</ServiceName>
</ServiceInfo>
<ParticipatingAppInfo>
<Name>Siebel</Name>
<Version>8.0</Version>
</ParticipatingAppInfo>
<Request xmlns="urn:oasis:names:tc:xacml:2.0:context:schema:cd:04"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="
urn:oasis:names:tc:xacml:2.0:context:schema:cd:04
http://docs.oasis-open.org/xacml/access_
control-xacml-2.0-context-schema-cd-04.xsd">
<Subject>
<Attribute AttributeId="siebel:user" DataType="xs:string">
<AttributeValue>SAdmin</AttributeValue>
</Attribute>
<Attribute AttributeId="siebel:org" DataType="xs:string">
<AttributeValue>siebl1</AttributeValue>
</Attribute>
</Subject>
<Resource>
</Resource>
<Action>
</Action>
<Environment/>
</Request>
</AIAAppContext>
属性名には次のガイドラインを使用します。
サービス情報の属性:
AIA:Service:Name - 変換サービスをコールするサービスの名前
参加アプリケーション情報の属性:
AIA:ParticipatingApp:Name - 参加アプリケーションの名前
AIA:ParticipatingApp:Version - 参加アプリケーションのバージョン
AIA:ParticipatingApp:SystemID - 参加アプリケーションの一意識別子
アプリケーションの属性:
アプリケーションのすべての属性について、「アプリケーション名: 属性名」のネーミング規則の使用をお薦めします。
アプリケーションのニュートラル属性:
アプリケーションのすべてのニュートラル属性について、AIAを接頭辞として使用することをお薦めします。これまでに識別されているアプリケーションのニュートラル属性は次のとおりです。
User: ユーザーを表します。
BusinessUnit: 組織または営業単位を表します。
標準セキュリティ・コンテキストは、エンタープライズ・ビジネス・メッセージ(EBM)に挿入されます。EBMは様々なEBSおよびEBFを介して宛先ABCSに伝播されるため、セキュリティ・コンテキストは、EBMとともにターゲットABCSに伝播され、そこでターゲット・アプリケーションに伝播するために使用されます。
次の項では、リクエスタ側とプロバイダ側の両方でアプリケーション・セキュリティ・コンテキストを実装するための高度なステップを示します。
リクエスタ側アプリケーション・セキュリティ・コンテキストを実装する手順は、次のとおりです。
プロバイダ側アプリケーション・セキュリティ・コンテキストを実装する手順は、次のとおりです。
