| Oracle® Fusion Middleware Oracle Web Services ManagerによるWebサービスの保護とポリシーの管理 12c (12.1.3) E59414-02 |
|
 前 |
 次 |
| Oracle® Fusion Middleware Oracle Web Services ManagerによるWebサービスの保護とポリシーの管理 12c (12.1.3) E59414-02 |
|
前 |
次 |
この章では、認可の構成方法を説明します。認可(アクセス制御とも呼ばれる)により、認証されたクライアントがどの操作にアクセスできるかを決定できます。
この章の内容は次のとおりです。
多くの場合、認証はユーザーにWebサービスへのアクセスを許可するかどうかを決定する最初の手順となります。ユーザーが認証されたら、2番目の手順は、ユーザーがWebサービスへのアクセスを認可されていることを検証することです。これは、認可ポリシーを使用して実行されます。binding_authorization_templateまたはcomponent_authorization_templateアサーション・テンプレートを使用して、認可ポリシーを作成できます。
これらのテンプレートを使用して作成されたポリシーでは、ロール・ベースまたは権限ベースのアクセス制御(RBAC)が実行され、認証されたユーザーにWebサービスへのアクセスが許可されたいずれかのロールまたは権限が付与されていることが確認されます。
現在のリリースで使用可能な認可ポリシーのサマリーは、第3章「使用する事前定義済ポリシーの決定」の「認可ポリシー」を参照してください。第17章「事前定義済ポリシー」には、認可を実行するセキュリティ・ポリシーがまとめられ、ポリシーがトランスポート・レイヤーまたはSOAPヘッダーで実行されるかどうかが示されています。
認可の詳細は、『Oracle Web Services Managerの理解』の認可の概要に関する項を参照してください。
|
注意: 認可ポリシーは、サブジェクトが作成されている任意の認証ポリシーの後に続けることができます。permitallおよびdenyallポリシーの両方を同じWebサービスに添付することはできません。 |
認可ポリシーには、ポリシーで保護するリソースを指定するために使用できる次のプロパティがあります。すべての事前定義済ポリシーにすべてのプロパティを設定できるとはかぎりません。
|
注意: 事前定義済ポリシーは読取り専用であり、編集できません。ただし、ベースとして事前定義済ポリシーを使用して新しいポリシーを作成できます。新しいポリシーの作成の詳細は、「Webサービス・ポリシーの作成および編集」を参照してください。新しいポリシーを作成したら、必要に応じて、ポリシーの編集や設定の変更、または構成プロパティの設定が行えます。 |
制約一致 -- 認可チェックが実行される制約を表す式。制約式は、次の2つのmessageContextプロパティを使用して指定します。
messageContext.authenticationMethod: ユーザーの認証に使用する認証方法を決定します。有効な値は、SAML_SVのみです。
messageContext.requestOrigin: リクエストが内部ネットワークまたは外部ネットワークから発行されたかどうかを決定します。このプロパティは、Oracleを使用しており、Oracle HTTP Server管理者がカスタムのVIRTUAL_HOST_TYPEヘッダーをリクエストに追加した場合のみ有効です。リクエストへのこのヘッダーの追加の詳細は、「リクエスト元を指定するためのOracle HTTP Serverの構成」を参照してください。
次の点に注意してください。
制約一致プロパティとその値では、大文字と小文字が区別されます。
制約式では、サポートされている標準的な演算子(==、!=、&&、||、!)を使用します。
次の例では、現在のメッセージにSAML_SVトークンが含まれない場合またはリクエスト元が内部でない場合のみ、ロールベースの認可アサーションが実行されます。
${!(messageContext.authenticationMethod =='SAML_SV'|| messageContext.requestOrigin == 'internal')}
|
注意: このプロパティは、binding_authorization_templateに基づく認可ポリシーでのみ有効です。他の認可アサーション・テンプレートに基づくポリシーの場合、このプロパティは今後の使用のために予約されています。 |
アクション一致 -- 権限ベースの確認が実行されるWebサービス操作。この値は、値のカンマ区切りのリストにすることもできます。このフィールドではワイルドカードを使用できます。*は、すべてのサービス操作を意味します。
「アクション一致」の有効な値は、Webサービス・メソッドで決まります。たとえば、Webサービス・メソッドがvalidate(amountAvailable)の場合は、アクション・パターンをvalidateと入力します。
リソース一致 -- 権限ベースの確認が実行されるリソースの名前。このフィールドではワイルドカードを使用できます。デフォルトは*で、ポリシーによって保護されるWebサービスのすべてのリソースに対応します。
表記規則により、リソース・パターンを(Webサービスのネームスペース+ Webサービス名)として入力します。
たとえば、Webサービスのネームスペースがhttp://project11で、Webサービス名がCreditValidationの場合、リソース名をhttp://project11/CreditValidationと入力します。
特定のリソース一致を指定した場合、ポリシーは、基準と一致するWebサービスに対してのみ実行されます。つまり、特定のリソース一致フィールドの値を入力すると、認可ポリシーのスコープが制限されます。デフォルトの*により、一括アタッチされたWebサービスのすべてのリソース(Webサービスのネームスペース+ Webサービス名)が保護されます。
権限クラス -- デフォルトでは、oracle.wsm.security.WSFunctionPermissionになっています。クラスは、クラスパスに存在する必要があります。
ロール -- 可能な値は、「すべてを許可」、「すべてを拒否」および「選択したロール」です。「選択したロール」を選択した場合、WebLogic Serverで定義されたエンタープライズ(グローバル)ロールのいずれかを選択する必要があります。このロールには、次のものがあります。
AdminChannelUser
Anonymous
AppTester
CrossDomainConnector
Deployer
Monitor
Operator
OracleSystemRole
概念的には、認証されたサブジェクトがWebサービス・ポリシーによって保護された特定のリソースへのアクセスを許可されるかどうかの決定には、連携して機能する2つの部分が関与します。
認可ポリシーの「アサーション」詳細ページの「リソース一致」および「アクション一致」パラメータにより、図11-1に示すように、ポリシーで保護するリソースが決定されます。
oracle/binding_permission_authorization_policyには、異なるアクションおよびリソースを設定するために使用可能なresourceおよびaction構成プロパティも含まれています。これらのプロパティを設定するか、オーバーライドする場合、「リソース一致」および「アクション一致」パラメータを使用して構成するアクションおよびリソースのかわりに、新しい値がアタッチされたWebサービスで使用されます。構成オーバーライドの使用方法の詳細は、第5章「ポリシー構成プロパティのオーバーライド」を参照してください。
そのポリシーの「権限クラス」設定を変更する方法もあります。これはJAAS標準によって権限クラスを識別します。権限クラスは、アプリケーションまたはサーバーのクラスパスに存在する必要があります。
カスタムの権限クラスは、抽象的な権限クラスを拡張し、シリアライズ可能なインタフェースを実装する必要があります。http://docs.oracle.com/javase/7/docs/api/java/security/Permission.htmlにあるJavadocを参照してください。デフォルトは、oracle.wsm.security.WSFunctionPermissionです。
OPSSアプリケーション・ポリシー・ページでは、図11-2に示すように、認証されたサブジェクトがそこにリストされている「リソース名」への起動アクセスを持つかどうかを指定します。
OPSSは、Webサービスの認可ポリシーの「アサーション」詳細ページを使用して、許可チェックが必要なリソースを決定します。認証されたサブジェクトがそのリソースに対してOPSSを介してWSFunctionPermission(または他の権限)を付与されている場合は、そのリソースへのアクセスが許可されます。
|
注意: そのポリシーの構成プロパティ「権限チェック・クラス」を変更する場合は、ここでもカスタム・クラスを使用してください。 |
認可ポリシーの「アサーション詳細」ページで、http://project11/CreditValidation Webサービスのvalidateメソッドを保護するために次のものを指定しているとします。
Action Match: validate Resource Match: http://project11/CreditValidation Permission Class oracle.wsm.security.WSFunctionPermission
次に、OPSSアプリケーション・ポリシー・ページで、「リソース名」にhttp://project11/CreditValidation#validateを使用して、認証されたサブジェクトがこのリソースを起動する権限を持つように指定します。
Permission Class: oracle.wsm.security.WSFunctionPermission Resource Name: http://project11/CreditValidation#validate Permissions Action: invoke
WSFunctionPermission権限を、ユーザー、グループまたはアプリケーション・ロールに付与できます。WSFunctionPermissionをユーザーまたはグループに付与した場合、この権限は、ドメインにデプロイされているすべてのアプリケーションに適用されます。
|
注意: OPSSリソース名にオペレーション名を組み込むことができます。 |
前のリリースのFusion Middleware Controlでは、OPSSアプリケーション・ポリシー・ページの「リソース名」は、name-space-of-webservice/ServiceNameによって決められていました。たとえば、Webサービスのネームスペースがhttp://project1/で、サービス名がCreditValidationの場合、「リソース名」はhttp://project1/CreditValidationでした。アスタリスク(*)ワイルドカードを使用して、すべてのアクションまたはすべてのリソースに権限を与えることもできました。
このリリースでは、WSFunctionPermissionのリソース・ターゲットに実際のWebサービス操作の名前を含めるように機能強化されました。「リソース名」の構文は、name-space-of-webservice/servicename#[オペレーション名]です。
(コンポーネントの場合はcompositename/componentname#[オペレーション名])
少なくともname-space-of-webservice/service nameを含める必要があります。つまり、アスタリスク(*)ワイルドカードを使用して、すべてのアクションまたはすべてのリソースに権限を与えることはできなくなりました。
そのかわりに、単に操作名を空白のままにしておくだけで、Webサービスのすべての操作を指定できます。たとえば、name-space-of-webservice/servicename#のようにします。
Permission Actionは常にinvokeです。
『Oracle Web Services Managerの理解』のOracle Entitlements Serverの統合の理解に関する項で説明されているように、Oracle Entitlements Server (OES)はファイングレイン認可サービスで、アプリケーションやサービスをエンドツーエンドで企業全体にわたって保護するために使用できます。OESはOWSMと統合されており、OESをOWSMとあわせてファイングレイン認可に使用できます。
Oracle Entitlements Serverの統合の理解に関する項では、リソースの処理方法の説明を含め、OESの統合の構成に必要な概念的情報が説明されています。また、その項では労働の分離も説明されています。OESポリシーおよび責任はOESコンソールから構成し、OWSM OESポリシーはFusion Middleware Control、WLSTまたはJDeveloperのようなツールから構成します。まだ読んでいない場合は、まずその項を読んでください。
この項では、OES統合の構成方法を説明しており、内容は次のとおりです。
OWSMインストール以外に、既存のOESコンソールのバージョン11.1.2.2.0以上が構成されている必要があります。OESはOWSMと同じマシンで同じOracle Middlewareホームにインストールされている必要があります。
OESはOracle Identity and Access Management Suiteの一部で、次のドキュメントで説明されています。この項は、これらの内容と、OESの構成および管理を理解していることを前提としています。
インストール方法の詳細は、『Oracle Identity and Access Managementインストレーション・ガイド』のOracle Entitlements Serverのインストールおよび構成に関する項を参照してください。
構成および管理の詳細は、『Oracle Entitlements Server管理者ガイド』を参照してください。
属性の処理方法に関する項で説明されているように、OESではOESコンソールで責任を作成し、複数の属性名と値のペアを設定できます。属性は、XPath、HTTPヘッダー、メッセージ・コンテキスト、定数(名前/値)、さらに認可リクエストで常に渡される静的属性のセット(serviceURLなど)から取得できます。
属性の情報を決定する最も簡単な方法は、アプリケーションをデプロイすることです。その後、SOAPリクエストまたはWSDLを確認し、必要な属性を決定します。2つの方法があります。
アプリケーションをデプロイし、JDeveloper (または別のメカニズム)を使用してSOAPメッセージを確認して必要なものを決定します。
アプリケーションをデプロイし、デプロイしたアプリケーションのWSDLを確認して必要なものを決定します。
Oracle Fusion Middlewareを使用したWebサービスの管理のWebサービスのWSDLドキュメントの表示に関する項の説明に従って、Webサービス・エンドポイントのWSDLドキュメントを表示します。
『Oracle Web Services Managerの理解』のOESの統合: 概観に関する項で説明されているように、認可決定のためにOESにアクセスするには、2段階方式(ファイングレイン)および1段階方式(大まか)の2種類の方法があります。この項では、ファイングレイン認可用にOESポリシーを構成する方法を説明します。
「OWSM OESポリシーのアタッチ」で説明されているように、後にOWSMポリシーをアタッチする際に、oracle/binding_oes_authorization_policyおよびoracle/component_oes_authorization_policyポリシーのuse.single.step属性で、どの方法を使用するかを指定します。ただし、OES認可ポリシーを適切に構成できるよう、使用する方法を決定する必要があります。
2段階方式の方がよく使用されるシナリオのため、通常、責任定義用の認可ポリシーと実際の認可決定用の認可ポリシーという、2つのOES認可ポリシーを構成することになります。
OESコンソールを使用して、基本的なアーティファクト(アプリケーション、リソース・タイプなど)を作成し、リソース・タイプにアクションを追加し、リソースを定義します。
この節では、以下のトピックについて説明します。
「リソースのマッピングと命名」で説明されているように、OESリソース名をOWSMリソース名にマッピングする必要があります。OWSMから認可コールを実行すると、リソース名がOESに渡されます。この名前はOESポリシーで定義されている名前と正確に一致する必要があります。
例として、次の特性を持つSOAP Webサービスをデプロイしたと仮定します。
デプロイしたアプリケーションの名前はHelloWorldServiceEarです。
リソース・タイプはWS_SERVICEです。
Webサービス名はHelloWorldServiceです。
Webサービスのポート名はSayHelloPortです。
Webサービス内の操作はsayHelloおよびsayHelloBytesです。
OESリソースを構成するには、次の手順を実行します。
OESアプリケーション名を作成します。アプリケーション名は、デプロイしたアプリケーション名と一致する必要があります。たとえば、HelloWorldServiceEarです。
OESリソース・タイプを作成します。リソース・タイプはWS_SERVICEである必要があります。
WS_SERVICEリソース・タイプにアクションを追加します。アクションはrequest.lookupおよびauthorizeである必要があります。
「リソース階層のサポート」コントロールを設定します。
階層を使用することにより、ポリシーをリソース・レベルまたはサブリソース(操作)レベルで定義できます。
OWSMリソース名には、サービス名、ポート名または操作名が含まれます。ただし、OESコンソールでリソースをこれだけ細かいレベルまで定義する必要はありません。たとえば、サービス名を持つポリシーを定義すると、そのサービスで始まるすべてのリソースに適用されます。または、サービス名とポート名が含まれるリソース名のポリシーを定義すると、このポリシーはそのサービスのすべての操作に適用されます。
「リソース階層のサポート」コントロールの設定方法は、『Oracle Entitlements Server管理者ガイド』のリソース・タイプの作成に関する項で説明されています。
リソースを作成します。リソース名には、サービス名、ポート名または操作名を含めることができます。
「OESリソースの構成」で作成したアプリケーション用に、新規のOES認可ポリシーを作成します。
リソースにアクセスを許可するプリンシパル(ロールおよびユーザー)を追加します。
このポリシーによって保護するターゲット(アクションを含む)を追加します。
図11-4に、画面の例を示します。
「責任」タブで、責任を追加します。
属性の処理方法に関する項で説明されているように、OESではOESコンソールで責任を作成し、複数の属性名と値のペアを設定できます。
属性は、XPath、HTTPヘッダー、メッセージ・コンテキスト、定数(名前/値)、さらに認可リクエストで常に渡される静的属性のセット(serviceURLなど)から取得できます。『Oracle Web Services Managerの理解』のOESポリシーでサポートされる属性タイプに関する項で説明されているように、これらの属性は特定の命名規則に従う必要があります。
例として、図11-5が表11-1の責任のサンプルからどのように導出され、それを反映しているかを確認してください。
これらの特定の責任名を使用する必要があり、大/小文字の区別がある点に注意してください。属性名は自分で選択できます。属性の値はリクエストの値と一致する必要があります。
|
注意: OESコンソールでは、責任名はアプリケーション全体で一意である必要があります。同じアプリケーションで同じタイプの責任を返すOESポリシーを複数定義する場合、同じ名前を使用できません。たとえば、xpath責任をpolicy1に追加した場合、同じアプリケーション内のpolicy2には追加できません。
責任名を一意にするために、次の命名規則を使用してください。 <
アプリケーション内に、責任を返すOESポリシーが1つしか存在せず、競合の可能性がない場合は、属性タイプをそのまま責任名として使用できます。 |
表11-1 ポリシーの責任のサンプル
| 責任名 | 属性名 | 属性値 |
|---|---|---|
|
xpath |
input |
//env:Envelope//env:Body/ns3:sayHello/arg0/text() |
|
namespace |
saml=urn:oasis:names:tc:SAML:1.0:assertion env=http://schemas.xmlsoap.org/soap/envelope/ ns3=http://helloworldservice.jaxws.wsmtest/ 各属性名をカンマ(,)で区切ります。例: |
|
|
saml_issuer |
//saml:Assertion/@Issuer |
|
|
|
proxy_auth |
Proxy-Authorization |
|
authHeader |
認可 |
|
|
|
authMethod |
oracle.wsm.internal.authentication.method |
|
endpoint |
oracle.j2ee.ws.runtime.endpoint-url |
|
|
|
org |
oracle |
|
country |
US |
実際の認可を実行するOES認可ポリシーを作成します。
このポリシーは、OWSMによって提供された責任を使用して、実際の認可決定を行います。
さらにOWSMからOESに、認証されたサブジェクト、ターゲット・リソースおよびリクエストされたアクション、さらに認可リクエストで常に渡される暗黙属性のセット(詳細はOESポリシーでサポートされる属性タイプに関する項を参照)が渡されます。認可ポリシーでは、認可決定にこれらの値を使用できます。時間、日付などのOESの定義済属性も使用できます。
実際の認可用のOES認可ポリシーを作成するには、次の手順を実行します。
認可条件で使用する属性を追加します。これらは、「責任を返す認可ポリシーの作成」で作成した責任に一致する必要があります。
たとえば、「責任を返す認可ポリシーの作成」で作成した責任に一致させるには、次の属性を追加する必要があります。
saml_issuer
input
authHeader
endpoint
country
|
注意: 暗黙属性(OESポリシーでサポートされる属性タイプに関する項を参照)を使用する場合は、それらも追加する必要があります。すべての属性と関数(カスタムおよび事前定義済の両方)は、アプリケーションの「拡張」ノードの下で、作成、収集、およびさらに管理されます。詳細は、『Oracle Entitlements Server管理者ガイド』の属性および関数の拡張としての管理に関する項を参照してください。 |
OESのナビゲーション・ペインで、認可ポリシーを作成しているアプリケーションを開きます。「拡張」を開き、「属性」を選択してアイコンをクリックし、新規属性を作成します。
ドロップダウン・コントロールから「保存して次を作成」を選択すると、1つのページから複数の属性を作成できます。
すべての新規属性をリソース・タイプに追加します。
「OESリソースの構成」で作成したアプリケーション用に、新規のOES認可ポリシーを作成します。
リソースにアクセスを許可するプリンシパル(ロールおよびユーザー)を追加します。
このポリシーによって保護するターゲット(アクションを含む)を追加します。
図11-7に、画面の例を示します。このポリシーは、ユーザーweblogicがHelloWorldServiceのsayHelloおよびsayHelloBytesリソースにアクセスする際に、認可を評価するように設定されています。
このポリシーの「条件」タブで、「編集」をクリックして新規条件を作成します。
図11-8で示されているように、手順1で追加した属性に基づいて条件を完成させます。
この例では、次の場合、ポリシーはPERMITを返します。
ユーザーがweblogicである。
リソースがHelloWorldServiceEar/ HelloWorldService/SayHelloPortである。
SAML発行者がwww.oracle.comである。
リクエストSOAPメッセージに、//env:Body/ns3:sayHello/arg0で「OWSM」がある。
他の条件が満たされている。
「OWSM OESポリシーのアタッチ」で説明されているように、OWSM OESポリシーをアタッチします。
『Oracle Web Services Managerの理解』のOESの統合: 概観に関する項で説明されているように、認可決定のためにOESにアクセスするには、2段階方式(ファイングレイン)および1段階方式(大まか)の2種類の方法があります。この項では、大まかな認可用にOESポリシーを構成する方法を説明します。
「OWSM OESポリシーのアタッチ」で説明されているように、後にOWSMポリシーをアタッチする際に、oracle/binding_oes_authorization_policyおよびoracle/component_oes_authorization_policyポリシーのuse.single.step属性で、どの方法を使用するかを指定します。ただし、OES認可ポリシーを適切に構成できるよう、使用する方法を決定する必要があります。
この項では、大まかな認可について次のトピックを説明します。
「リソースのマッピングと命名」で説明されているように、OESリソース名をOWSMリソース名にマッピングする必要があります。OWSMから認可コールを実行すると、リソース名がOESに渡されます。この名前はOESポリシーで定義されている名前と正確に一致する必要があります。
例として、次の特性を持つSOAP Webサービスをデプロイしたと仮定します。
デプロイしたアプリケーションの名前はHelloWorldServiceEarです。
リソース・タイプは常にWS_SERVICEです。
Webサービス名はHelloWorldServiceです。
Webサービスのポート名はSayHelloPortです。
Webサービス内の操作はsayHelloおよびsayHelloBytesです。
OESリソースを構成するには、次の手順を実行します。
OESアプリケーション名を作成します。アプリケーション名は、デプロイしたアプリケーション名と一致する必要があります。たとえば、HelloWorldServiceEarです。
OESリソース・タイプを作成します。リソース・タイプはWS_SERVICEである必要があります。
リソース・タイプにアクションを追加します。アクションはauthorizeである必要があります。
「リソース階層のサポート」コントロールを設定します。
階層を使用することにより、ポリシーをリソース・レベルまたはサブリソース(操作)レベルで定義できます。
OWSMリソース名には、サービス名、ポート名または操作名が含まれます。ただし、OESコンソールでリソースをこれだけ細かいレベルまで定義する必要はありません。たとえば、サービス名を持つポリシーを定義すると、そのサービスで始まるすべてのリソースに適用されます。または、サービス名とポート名が含まれるリソース名のポリシーを定義すると、このポリシーはそのサービスのすべての操作に適用されます。
「リソース階層のサポート」コントロールの設定方法は、『Oracle Entitlements Server管理者ガイド』のリソース・タイプの作成に関する項で説明されています。
リソースを作成します。リソース名は、リソース階層をどのように活用するかに合せ、service name/port name/operation nameの形式である必要があります。
実際の認可を実行するOES認可ポリシーを作成します。
OWSMからOESに、認証されたサブジェクト、ターゲット・リソースおよびリクエストされたアクション、さらに認可リクエストで常に渡される暗黙属性のセット(詳細はOESポリシーでサポートされる属性タイプに関する項を参照)が渡されます。
認可ポリシーでは、認可決定にこれらの値を使用できます。時間、日付などのOESの定義済属性も使用できます。
実際の認可用のOES認可ポリシーを作成するには、次の手順を実行します。
暗黙属性(OESポリシーでサポートされる属性タイプに関する項を参照)を使用する場合は、それらを追加する必要があります。
|
注意: すべての属性と関数(カスタムおよび事前定義済の両方)は、アプリケーションの「拡張」ノードの下で、作成、収集、およびさらに管理されます。詳細は、『Oracle Entitlements Server管理者ガイド』の属性および関数の拡張としての管理に関する項を参照してください。 |
OESのナビゲーション・ペインで、認可ポリシーを作成しているアプリケーションを開きます。「拡張」を開き、「属性」を選択してアイコンをクリックし、新規属性を作成します。
ドロップダウン・コントロールから「保存して次を作成」を選択すると、1つのページから複数の属性を作成できます。
図11-10で示されているように、リソース・タイプで使用するすべての暗黙属性を追加します。
「OESリソースの構成」で作成したアプリケーション用に、新規のOES認可ポリシーを作成します。
リソースにアクセスを許可するプリンシパル(ロールおよびユーザー)を追加します。
このポリシーによって保護するターゲット(アクションを含む)を追加します。
図11-11に、画面の例を示します。
「OWSM OESポリシーのアタッチ」で説明されているように、OWSM OESポリシーをアタッチします。
この節では、以下のトピックについて説明します。
「リソースのマッピングと命名」で説明されているように、OESリソース名をOWSMリソース名にマッピングする必要があります。OWSMからマスキング・コールを実行すると、リソース名がOESに渡されます。この名前はOESポリシーで定義されている名前と正確に一致する必要があります。
例として、次の特性を持つSOAP Webサービスをデプロイしたと仮定します。
デプロイしたアプリケーションの名前はHelloWorldServiceEarです。
リソース・タイプは常にWS_SERVICEです。
Webサービス名はHelloWorldServiceです。
Webサービスのポート名はSayHelloPortです。
Webサービス内の操作はsayHelloおよびsayHelloBytesです。
OESリソースを構成するには、次の手順を実行します。
まだOESアプリケーション名を作成していない場合は、ここで作成します。アプリケーション名は、デプロイしたアプリケーション名と一致する必要があります。たとえば、HelloWorldServiceEarです。
まだOESリソース・タイプを作成していない場合は、ここで作成します。リソース・タイプはWS_SERVICEである必要があります。
まだリソース・タイプにアクションを追加していない場合は、ここで追加します。アクションはresponse.lookupおよびmaskである必要があります。
まだ「リソース階層のサポート」コントロールを設定していない場合は、ここで設定します。
「リソース階層のサポート」コントロールの設定方法は、『Oracle Entitlements Server管理者ガイド』のリソース・タイプの作成に関する項で説明されています。
まだリソースを作成していない場合は、ここで作成します。リソース名は、リソース階層をどのように活用するかに合せ、service name/port name/operation nameの形式である必要があります。
「OESリソースの構成」で作成したアプリケーション用に、新規のOESポリシーを作成します。
リソースにアクセスを許可するプリンシパル(ロールおよびユーザー)を追加します。
このポリシーによって保護するターゲット(アクションresponse.lookupを含む)を追加します。
「責任」タブで、責任を追加します。
属性の処理方法に関する項で説明されているように、OESではOESコンソールで責任を作成し、複数の属性名と値のペアを設定できます。
このマスキングのユースケースの場合は、マスキングする属性を取得するXPath問合せのセットを作成します。
これらの責任の結果、OWSMはすべての定義済属性およびXpath問合せを取得し、それらを現在のレスポンスSOAPメッセージで実行します。(このコールで何も返されなかった場合は、実行が停止され、マスキングは実行されません。)OWSMではこの問合せの結果を使用して、「実際のOESマスキング・ポリシーの作成」で説明されている実際のマスキング・ポリシーを呼び出します。
実際のマスキング・ポリシーの責任を作成する際には、この責任の属性名を使用します。
実際のマスキングを実行するOES認可ポリシーを作成します。
このポリシーは、OWSMによって提供された責任を使用して、実際のマスキング決定を行います。
実際のマスキング用のOESポリシーを作成するには、次の手順を実行します。
条件で使用する属性を追加します。
暗黙属性(OESポリシーでサポートされる属性タイプに関する項を参照)を使用する場合は、それらも追加する必要があります。
|
注意: すべての属性と関数(カスタムおよび事前定義済の両方)は、アプリケーションの「拡張」ノードの下で、作成、収集、およびさらに管理されます。詳細は、『Oracle Entitlements Server管理者ガイド』の属性および関数の拡張としての管理に関する項を参照してください。 |
OESのナビゲーション・ペインで、認可ポリシーを作成しているアプリケーションを開きます。「拡張」を開き、「属性」を選択してアイコンをクリックし、新規属性を作成します。
ドロップダウン・コントロールから「保存して次を作成」を選択すると、1つのページから複数の属性を作成できます。
すべての新規属性をリソース・タイプに追加します。
「OESリソースの構成」で作成したアプリケーション用に、新規のOES認可ポリシーを作成します。
リソースにアクセスを許可するプリンシパル(ロールおよびユーザー)を追加します。
このポリシーによって保護するターゲット(アクションmaskを含む)を追加します。
「責任」タブで、責任を追加します。
これらの責任により、属性がそのまま渡されるかマスキングされるかが指定されます。OWSMは、OESが返す責任を受け付け、OESによって機密データとマークされている属性はマスキングします。
属性と置換する値を返します。
たとえば、責任ポリシーでXPathをname=//env:Envelope//env:Body/ns3:sayHelloResponse/return/text()として追加した場合、マスキング・ポリシーではXPathの責任をname=xxxxxまたはname=****として追加します。ここで、nameは両方のポリシーで一致しています。
「OWSM OESポリシーのアタッチ」で説明されているように、OWSM OESポリシーをアタッチします。
事前定義済のoracle/binding_oes_authorization_policy、oracle/component_oes_authorization_policyまたはoracle/binding_oes_masking_policyのコピーを作成し、そのコピーをWebサービスにアタッチします。次のステップを実行します:
ナビゲータ・ペインで「WebLogicドメイン」を開き、OES統合の構成が必要なドメインを表示します。ドメインを選択します。
コンテンツ・ペインで、「WebLogicドメイン」→「Webサービス」→「ポリシー」の順にクリックします。
oracle/binding_oes_authorization_policy、oracle/component_oes_authorization_policyまたはoracle/binding_oes_masking_policyポリシーを選択してコピーを作成します。
コピーの属性を編集します。(かわりに、後の手順で説明するように属性をオーバーライドすることも可能です。)
use.single.step属性により、認可決定のためにOESにアクセスする方法が制御されます。2段階(ファイングレイン)方式または1段階(大まかな)方式です。デフォルトはfalseで、2段階(ファイングレイン)方式を使用します。一段階方式では責任を使用しませんが、条件で暗黙属性を使用できます。
この属性は、oracle/binding_oes_authorization_policyおよびoracle/component_oes_authorization_policyポリシーで設定できます。oracle/binding_oes_masking_policyは常に2段階方式です。
OESに基づいた認可設定では、リソース、アクションおよび制約のmatch値を定義するためにguard要素(orawsp:guardを参照)が使用されます。これらの値によって、guardの結果がtrueの場合にのみ、アサーション実行が許可されるようになります。つまり、アクセスしたリソース名およびアクションが一致した場合にのみ、アサーションの実行が許可されます。デフォルトで、リソース名およびアクションでは、ワイルドカードのアスタリスク(*)が使用され、すべてが許可されます。
OESポリシーの作成時にリソースの命名規則に従った場合は、リソース名を明示的に設定する必要はありません。
第4章「ポリシーのアタッチ」で説明されているように、設計時またはデプロイ後にポリシーをアタッチします。
OWSM oracle/binding_oes_authorization_policyポリシーまたはoracle/component_oes_authorization_policyポリシーを単体で、またはoracle/binding_oes_masking_policyポリシーと組み合せてアタッチします。
オプションで、Fusion Middleware Control、WLSTまたはJDeveloper (または他のメカニズム)を使用して属性をオーバーライドします。OESポリシーの作成時にリソースの命名規則に従った場合、リソース・プロパティのオーバーライドは必須ではありません。
オーバーライド可能な属性の説明は、「構成プロパティおよびオーバーライド」を参照してください。
構成ポリシーのオーバーライドの詳細は、第5章「ポリシー構成プロパティのオーバーライド」を参照してください。
第4章「ポリシーのアタッチ」で説明されているように、設計時またはデプロイ後に認証ポリシーもアタッチします。
表11-2に示されているポリシーの構成プロパティは、ポリシーをアタッチする際に設定するか、オーバーライドできます。
OESポリシーの作成時にリソースの命名規則に従った場合、リソース名は導出され、プロパティのオーバーライドは必須ではありません。
一部の値のみオーバーライドし、残りはしなかった場合、残りは導出されます。
表11-2 OWSM OES構成プロパティ
| Name | 説明 |
|---|---|
|
|
OESに定義されたデプロイされたアプリケーション名。(SOAの場合、コンポジット名がアプリケーション名として使用されます。) ${}表記法を使用した値は、静的にも動的にもできます。 |
|
|
OESに定義されたリソース・タイプ。${}表記法を使用した値は、静的にも動的にもできます。
|
|
|
OESに定義されたリソース名。${}表記法を使用した値は、静的にも動的にもできます。
|
|
|
属性の参照時に使用されるアクションです。 ${}表記法を使用した値は、静的にも動的にもできます。 |
|
|
実際の認可またはマスキングで使用されるアクションです。デフォルト値は、認可ユースケースでは ${}表記法を使用した値は、静的にも動的にもできます。 |
|
|
参照フェーズを省略するには、値をtrueに設定します。マスキング・ポリシーには適用されません。 |
|
|
ポリシー・アタッチメントの優先度を指定するオプションのプロパティ。 |
これらのプロパティでは、静的および動的値の両方を使用できます。動的値は1つ以上の${}演算子を使用し、ピリオドまたはスラッシュなどのセパレータ文字を使用できます。たとえば、resource.nameの値を${PORT}/${OPERATION}と指定した場合、それはmyPort/operationと解決されます。別の例として、${MODULE}.${SERVICE}はmyModule.myServiceと解決されます。
指定可能な動的値は次のとおりです。
APPLICATION
MODULE
SERVICE (SOAPおよびSOA参照の場合はWSDL Webサービス名です。
PORT (WSDLサービスのポート名)
OPERATION (SOAPのWebサービス操作。)
COMPOSITE (SOAコンポジット名)
COMPONENT (SOAコンポーネント名)
NAMESPACE
制約一致プロパティ設定には、リクエストが内部ネットワークまたは外部ネットワークから発行されたかどうかを指定するrequestOriginフィールドが含まれています。このプロパティは、Oracle HTTP Serverを使用しており、Oracle HTTP Server管理者がカスタムのVIRTUAL_HOST_TYPEヘッダーをリクエストに追加した場合のみ有効です。
リクエスト元を指定するためにOracle HTTP Serverを構成するには、管理者が次のようにhttpd.confファイルを変更する必要があります。
mod_headersモジュールがロードされていることを確認します。
RequestHeader内でVIRTUAL_HOST_TYPEヘッダー名を設定します。有効な値は、internalおよびexternalです。次のコマンド構文を使用します。
RequestHeader set|append|add|unset header [value [env=[!]variable]]
たとえば、内部リクエストの仮想ホストを構成するには、次のように指定します。
<VirtualHost *:7777> RequestHeader set VIRTUAL_HOST_TYPE "internal" </VirtualHost>
外部リクエストの仮想ホストを構成するには、次のように指定します。
<VirtualHost *:8888> RequestHeader set VIRTUAL_HOST_TYPE "external" </VirtualHost>
これらの例で、プライベート・ネットワークの外部からのすべてのリクエストは、virtual host:8888を経由してルーティングされ、内部プライベート・ネットワークからのすべてのリクエストは、virtual host:7777を経由してルーティングされます。
アプリケーションを外部のポートでも使用できるように、これらのポートをリスニング・ポートとしてhttpd.confファイルに追加する必要もあります。
Oracle HTTP Serverを再起動します。
