| Oracle® Fusion Middleware Oracle Web Services ManagerによるWebサービスの保護とポリシーの管理 12c (12.2.1.1) E79324-01 |
|
 前 |
 次 |
| Oracle® Fusion Middleware Oracle Web Services ManagerによるWebサービスの保護とポリシーの管理 12c (12.2.1.1) E79324-01 |
|
|
前 |
次 |
多くの場合、認証はユーザーにWebサービスへのアクセスを許可するかどうかを決定する最初の手順となります。ユーザーが認証されたら、2番目の手順は、ユーザーがWebサービスへのアクセスを認可されていることを検証することです。これは、認可ポリシーを使用して実行されます
binding_authorization_templateまたはcomponent_authorization_templateアサーション・テンプレートを使用して、認可ポリシーを作成できます。
これらのテンプレートを使用して作成されたポリシーでは、ロール・ベースまたは権限ベースのアクセス制御(RBAC)が実行され、認証されたユーザーにWebサービスへのアクセスが許可されたいずれかのロールまたは権限が付与されていることが確認されます。
現在のリリースで使用可能な認証ポリシーのサマリーは、Webサービスに使用する事前定義済ポリシーの決定の認可ポリシーを参照してください。Oracle Web Services Managerの事前定義済ポリシーに、認可を実行するセキュリティ・ポリシーをまとめ、ポリシーがトランスポート・レイヤーまたは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つの部分が関与します。
認可ポリシーの「アサーション」詳細ページのリソース一致およびアクション一致パラメータにより、図10-1に示すように、ポリシーで保護するリソースが決定されます。
oracle/binding_permission_authorization_policyには、異なるアクションおよびリソースを設定するために使用可能なresourceおよびaction構成プロパティも含まれています。これらのプロパティを設定するか、オーバーライドする場合、「リソース一致」および「アクション一致」パラメータを使用して構成するアクションおよびリソースのかわりに、新しい値がアタッチされたWebサービスで使用されます。構成オーバーライドの使用方法の詳細は、「ポリシー構成プロパティのオーバーライド」を参照してください。
そのポリシーの「権限クラス」設定を変更する方法もあります。これはJAAS標準によって権限クラスを識別します。権限クラスは、アプリケーションまたはサーバーのクラスパスに存在する必要があります。
カスタムの権限クラスは、抽象的な権限クラスを拡張し、シリアライズ可能なインタフェースを実装する必要があります。http://docs.oracle.com/javase/7/docs/api/java/security/Permission.htmlにあるJavadocを参照してください。デフォルトは、oracle.wsm.security.WSFunctionPermissionです。
OPSSアプリケーション・ポリシー・ページでは、図10-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をユーザーまたはグループに付与した場合、この権限は、ドメインにデプロイされているすべてのアプリケーションに適用されます。
WSFunctionPermissionのリソース・ターゲットは、実際のWebサービス操作の名前を含めるように機能強化されました。OPSSリソース名にオペレーション名を組み込むことができます。
注意:
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 Entitlements Server (OES)は、エンドツーエンドでエンタープライズ全体のアプリケーションとサービスを保護するために使用できるファイングレイン認可サービスです。OESはOWSMと統合されており、OESをOWSMとあわせてファイングレイン認可に使用できます。
『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など)から取得できます。
属性の処理方法に関する項で説明されているように、OESではOESコンソールで責任を作成し、複数の属性名と値のペアを設定できます。属性は、XPath、HTTPヘッダー、メッセージ・コンテキスト、定数(名前/値)、さらに認可リクエストで常に渡される静的属性のセット(serviceURLなど)から取得できます。
属性の情報を決定する最も簡単な方法は、アプリケーションをデプロイすることです。その後、SOAPリクエストまたはWSDLを確認し、必要な属性を決定します。2つの方法があります。
アプリケーションをデプロイし、JDeveloper (または別のメカニズム)を使用してSOAPメッセージを確認して必要なものを決定します。
アプリケーションをデプロイし、デプロイしたアプリケーションのWSDLを確認して必要なものを決定します。
Oracle Fusion Middlewareを使用したWebサービスの管理のWebサービスのWSDLドキュメントの表示に関する項の説明に従って、Webサービス・エンドポイントのWSDLドキュメントを表示します。
OESに対して認可の決定を問い合せるには、2段階の方法(ファイングレイン)と1段階の方法(大まか)の2通りがあります。この項では、ファイングレイン認可用に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認可ポリシーを適切に構成できるよう、使用する方法を決定する必要があります。
2段階方式の方がよく使用されるシナリオのため、通常、責任定義用の認可ポリシーと実際の認可決定用の認可ポリシーという、2つのOES認可ポリシーを構成することになります。
OESコンソールを使用して、基本的なアーティファクト(アプリケーション、リソース・タイプなど)を作成し、リソース・タイプにアクションを追加し、リソースを定義します。
この節では、以下のトピックについて説明します。
OESリソース名は、OWSMリソース名にマップする必要があります。OWSMから認可コールを実行すると、リソース名がOESに渡されます。この名前はOESポリシーで定義されている名前と正確に一致する必要があります。
「リソースのマッピングと命名」で説明されているように、OESリソース名をOWSMリソース名にマッピングする必要があります。OWSMから認可コールを実行すると、リソース名がOESに渡されます。この名前はOESポリシーで定義されている名前と正確に一致する必要があります。
例として、次の特性を持つSOAP Webサービスをデプロイしたと仮定します。
デプロイしたアプリケーションの名前はHelloWorldServiceEarです。
リソース・タイプはWS_SERVICEです。
Webサービス名はHelloWorldServiceです。
Webサービスのポート名はSayHelloPortです。
Webサービス内の操作はsayHelloおよびsayHelloBytesです。
OESリソースを構成するには、次の手順を実行します。
HelloWorldServiceEarです。この手順を使用すると、責任を返す認可ポリシーを作成できます。
責任を返す認可ポリシーを作成するには、次の手順に従います。
属性の処理方法に関する項で説明されているように、OESではOESコンソールで責任を作成し、複数の属性名と値のペアを設定できます。
属性は、XPath、HTTPヘッダー、メッセージ・コンテキスト、定数(名前/値)、さらに認可リクエストで常に渡される静的属性のセット(serviceURLなど)から取得できます。『Oracle Web Services Managerの理解』のOESポリシーでサポートされる属性タイプに関する項で説明されているように、これらの属性は特定の命名規則に従う必要があります。
例として、この項の次の表に示されているサンプルの責任がどのように抽出されて、図10-5に反映されているかを考えてみてください。
これらの特定の責任名を使用する必要があり、大/小文字の区別がある点に注意してください。属性名は自分で選択できます。属性の値はリクエストの値と一致する必要があります。
注意:
OESコンソールでは、責任名はアプリケーション全体で一意である必要があります。同じアプリケーションで同じタイプの責任を返すOESポリシーを複数定義する場合、同じ名前を使用できません。たとえば、xpath責任をpolicy1に追加した場合、同じアプリケーション内のpolicy2には追加できません。
責任名を一意にするために、次の命名規則を使用してください。
<attribute_type>:<obligation_name>
attribute_typeは、XPath、HTTPHeaderまたはMessageContextなどのサポートされているタイプのいずれかです。obligation_nameは一意になる任意の名前を使用できます。
アプリケーション内に、責任を返すOESポリシーが1つしか存在せず、競合の可能性がない場合は、属性タイプをそのまま責任名として使用できます。
| 責任名 | 属性名 | 属性値 |
|---|---|---|
xpath |
input |
//env:Envelope//env:Body/ns3:sayHello/arg0/text() |
xpath |
namespace |
saml=urn:oasis:names:tc:SAML:1.0:assertion env=http://schemas.xmlsoap.org/soap/envelope/ ns3=http://helloworldservice.jaxws.wsmtest/ 各属性名をカンマ(,)で区切ります。例: |
xpath |
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つのページから複数の属性を作成できます。
リソースにアクセスを許可するプリンシパル(ロールおよびユーザー)を追加します。
このポリシーによって保護するターゲット(アクションを含む)を追加します。
図10-7に、画面の例を示します。このポリシーは、ユーザーweblogicがHelloWorldServiceのsayHelloおよびsayHelloBytesリソースにアクセスする際に、認可を評価するように設定されています。
この項は、大まかな認可用に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リソースを構成できます。
「リソースのマッピングと命名」で説明されているように、OESリソース名をOWSMリソース名にマッピングする必要があります。OWSMから認可コールを実行すると、リソース名がOESに渡されます。この名前はOESポリシーで定義されている名前と正確に一致する必要があります。
例として、次の特性を持つSOAP Webサービスをデプロイしたと仮定します。
デプロイしたアプリケーションの名前はHelloWorldServiceEarです。
リソース・タイプは常にWS_SERVICEです。
Webサービス名はHelloWorldServiceです。
Webサービスのポート名はSayHelloPortです。
Webサービス内の操作はsayHelloおよびsayHelloBytesです。
OESリソースを構成するには、次の手順を実行します。
HelloWorldServiceEarです。この手順を使用すると、実際の認可を実行するOES認可ポリシーを作成できます。
実際の認可を実行するOES認可ポリシーを作成するには、この手順に従います。
OWSMからOESに、認証されたサブジェクト、ターゲット・リソースおよびリクエストされたアクション、さらに認可リクエストで常に渡される暗黙属性のセット(詳細はOESポリシーでサポートされる属性タイプに関する項を参照)が渡されます。
認可ポリシーでは、認可決定にこれらの値を使用できます。時間、日付などのOESの定義済属性も使用できます。
実際の認可用のOES認可ポリシーを作成するには、次の手順を実行します。
この項は、マスキング用にOESポリシーを構成する方法を理解するために役立ちます。
次の項は、マスキング用にOESポリシーを構成する方法について説明しています。
OESリソース名は、OWSMリソース名にマップする必要があります。OWSMからマスキング・コールを実行すると、リソース名がOESに渡されます。この名前はOESポリシーで定義されている名前と正確に一致する必要があります。
「リソースのマッピングと命名」で説明されているように、OESリソース名をOWSMリソース名にマッピングする必要があります。OWSMからマスキング・コールを実行すると、リソース名がOESに渡されます。この名前はOESポリシーで定義されている名前と正確に一致する必要があります。
例として、次の特性を持つSOAP Webサービスをデプロイしたと仮定します。
デプロイしたアプリケーションの名前はHelloWorldServiceEarです。
リソース・タイプは常にWS_SERVICEです。
Webサービス名はHelloWorldServiceです。
Webサービスのポート名はSayHelloPortです。
Webサービス内の操作はsayHelloおよびsayHelloBytesです。
OESリソースを構成するには、次の手順を実行します。
HelloWorldServiceEarです。この項は、OWSM OESポリシーをアタッチする方法を理解するために役立ちます。
この項では、OWSM OESポリシーをアタッチする方法について説明します。
この手順を使用すると、OWSM OESポリシーをアタッチできます。
事前定義済のoracle/binding_oes_authorization_policy、oracle/component_oes_authorization_policyまたはoracle/binding_oes_masking_policyのコピーを作成し、そのコピーをWebサービスにアタッチします。次の手順を実行します。
構成プロパティはこの項で説明するように設定できます。
表10-1に示されているポリシーの構成プロパティは、ポリシーをアタッチする際に設定するか、オーバーライドできます。
OESポリシーの作成時にリソースの命名規則に従った場合、リソース名は導出され、プロパティのオーバーライドは必須ではありません。
一部の値のみオーバーライドし、残りはしなかった場合、残りは導出されます。
表10-1 OWSM OES構成プロパティ
| 名前 | 説明 |
|---|---|
|
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
この手順を使用すると、リクエスト元を指定するためにOracle HTTP Serverを構成できます。
制約一致プロパティ設定には、リクエストが内部ネットワークまたは外部ネットワークから発行されたかどうかを指定するrequestOriginフィールドが含まれています。このプロパティは、Oracle HTTP Serverを使用しており、Oracle HTTP Server管理者がカスタムのVIRTUAL_HOST_TYPEヘッダーをリクエストに追加した場合のみ有効です。
リクエスト元を指定するためにOracle HTTP Serverを構成するには、管理者が次のようにhttpd.confファイルを変更する必要があります。
この項では、Oracle Web Services ManagerでのOracle Mobile and Social OAuth2の認可フレームワークの使用方法について説明します。
この項では、Oracle Web Services ManagerでのOracle Mobile and Social OAuth2の認可フレームワークの使用方法について説明します。
注意:
この項では、Oracle Access Manager with Oracle Security Token Service管理者ガイドの次の項に記載された用語、概念および構成情報をよく理解していることを前提としています。
この項では、OAuth 2.0 Authorization Frameworkの仕様に基づくOracle Web Services ManagerでのOAuth2のサポートについて説明します。
Oracle Web Services ManagerでのOAuth2サポートは、OAuth 2.0 Authorization Framework (http://tools.ietf.org/html/rfc6749)の仕様に基づいています。
Oracle Web Services Managerでは、OAuth2.0プロトコル操作にOracle Mobile and Social OAuth2サービスを認可サーバーとして使用します。詳細は、Oracle Fusion Middleware Oracle Access Management管理者ガイドのMobile and Socialの理解に関する項を参照してください。
Oracle Web Services Managerでは、Webサービス・クライアントがMobile and Social OAuth2サーバーが実装するSOAPおよびRESTのWebサービスと対話し、2-legged認可を行うことができます。
2-legged OAuth2では、アプリケーション間で対話が行われ、ユーザーによる承認は必要ではありません。
クライアントは、リソース所有者からの承認を要求します。応答で、クライアントはリソース所有者の認可を示す資格証明、認可付与を受け取ります。その後、次の手順を実行します。
クライアントは、認可サーバーで認証し、認可付与を提示して、アクセス・トークン(AT)を要求します。
認可サーバーはクライアントを認証し、認可付与を検証して、有効であればATを発行します。
クライアントは、リソース・サーバーの保護されたリソースを要求し、ATを提示して認証します。
Oracle Web Services Managerサーバー側エージェントは、ATを検証し、有効な場合は要求を受け入れ、無効な場合は要求を拒否します。
クライアント・アプリケーションに、OAuth2クライアント・ポリシー(oracle/http_oauth2_token_client_policy、oracle/oauth2_config_client_policyなど)を割り当てます。oracle/oauth2_config_client_policyポリシーの必須プロパティtoken.uriは、OAuth2サーバーのトークン・エンドポイントを指定します。
次の任意のOracle Web Services Manager JWTサービス・ポリシーもWebサービスに割り当てます。Oracle Web Services Managerのサーバー側エージェントがアクセス・トークンを検証します。
oracle/http_jwt_token_service_policy
oracle/http_jwt_token_over_ssl_service_policy
oracle/multi_token_rest_service_policy
oracle/multi_token_over_ssl_rest_service_policy
oracle/wss11_saml_or_username_token_with_message_protection_service_policy
oracle/http_oauth2_token_client_policy
oracle/http_oauth2_token_opc_oauth2_client_policy
oracle/http_oauth2_token_identity_switch_opc_oauth2_over_ssl_client_policy
oracle/http_oauth2_token_opc_oauth2_over_ssl_client_policy
oracle/http_oauth2_token_identity_switch_over_ssl_client_policy
oracle/http_oauth2_token_over_ssl_client_policy
oracle/http_oauth2_config_client_policy
認可付与は、リソース所有者の認可を表す資格証明です。
Oracle Web Services Managerでは、2-legged認可で次の認可付与タイプをサポートします。使用するタイプは、OAuth2 OWSMクライアント・プロファイルの構成時に指定します(Oracle Web Services Managerのポリシーと使用するためのOAuth2の構成を参照)。
クライアント資格証明付与: この場合、クライアント資格証明は「Authorization: Basic」HTTPヘッダーで送信されます(クライアント資格証明付与 - OAuth2.0認可フレームワークを参照)。
アタッチされたoauth2クライアント・ポリシーのfederated.client.tokenプロパティを設定して、使用するユーザー名とパスワードを指定します。
クライアント資格証明JWT (フェデレーション・ユースケース): この場合、クライアント資格証明はJWTアサーションとして送信されます(クライアント認証のためのJWTの使用を参照)。
Oracle Web Services Managerは、Oracle Web Services Manager資格証明ストアに保存されたクライアント資格証明に基づいてJWTトークンをローカルに生成します。クライアント・トークン・ポリシーのfederated.client.tokenプロパティを設定して、oauth2.client.csf.keyおよびkeystore.sig.csf.keyプロパティの値を使用してクライアントのJWTトークンを生成するかどうかを指定します。
oauth2.client.csf.keyプロパティおよびkeystore.sig.csf.keyプロパティの値を使用して、クライアントのJWTトークンが生成されます。federated.client.tokenプロパティがTrueに設定されていることを確認します。
クライアント資格証明がBasic認証ヘッダーで送信され、これに加えて、ユーザー資格証明がJWTアサーションで送信されます(クライアント資格証明付与 - OAuth2.0認可フレームワークおよびクライアント認証のためのJWTの使用を参照)。
アタッチされたoauth2クライアント・ポリシーのoauth2.client.csf.keyプロパティを設定して、Basic認証ヘッダーに使用するユーザー名とパスワードを指定します。
クライアント資格証明がJWTアサーションで送信され、これに加えて、ユーザー資格証明がJWTアサーションで送信されます(クライアント認証のためのJWTの使用を参照)。
クライアント資格証明は、OAuth2サーバーへのリクエストに常に含まれます。
federated.client.tokenプロパティにより、クライアント資格証明のクライアントIDにJWTを使用するか、またはクライアント資格証明のクライアントIDとパスワードを使用するかどうかが決まります。
federated.client.tokenがtrue (デフォルト)の場合は、JWTがクライアント資格証明のクライアントIDに使用されます。
federated.client.tokenがfalseの場合は、クライアント資格証明にクライアントIDとパスワードが使用されます。
subjectプロパティは、JWTトークンの作成のために使用するサブジェクトの取得場所を指定します。
subject.precedenceプロパティは、JWTトークンの作成のために使用するサブジェクトの取得場所を指定します。
表10-2に示すように、subject.precedenceをtrueに設定した場合、JWTトークンを作成するためのユーザー名は認証済サブジェクトからのみ取得されます。
subject.precedenceをfalseに設定した場合、JWTトークンを作成するためのユーザー名はcsf-keyプロパティからのみ取得されます。
表10-2 ユーザー資格証明、サブジェクトおよびアクセス・トークン
| subject.precedence | csf-key | 認証済ユーザー・サブジェクト | クライアント資格証明 | ユーザー資格証明 | アクセス・トークン・プリンシパル/サブジェクト |
|---|---|---|---|---|---|
True(デフォルト) |
該当なし |
使用可能 |
認証済エンド・ユーザーのJWT。 |
エンドユーザー名。 |
|
True(デフォルト) |
該当なし |
該当なし |
対象外 |
クライアントID |
|
False |
未構成(デフォルト) |
該当なし |
対象外 |
該当なし |
|
False |
構成済 |
該当なし |
csf-keyエントリからのアイデンティティのJWT。 |
csf-key/user nameからユーザー名が構成されます。 |
Oracle Web Services Managerとともに使用するためにMobile and Social OAuth2を構成する前提条件として、構成情報を理解している必要があります。
Oracle Web Services Managerとともに使用するためにMobile and Social OAuth2を構成する前提条件として、Oracle Access Manager with Oracle Security Token Service管理者ガイドで説明されている構成情報を理解している必要があります。
Oracle Web Services Managerとともに使用するためのOAuth2の構成の詳細は、Oracle Fusion Middleware Oracle Access Management管理者ガイドのOAuthサービスの構成に関する項を参照してください。
