Oracle® Fusion Middleware Oracle Web Services ManagerによるWebサービスの保護とポリシーの管理 12c (12.2.1.2) E82680-02 |
|
![]() 前 |
![]() 次 |
トピック:
多くの場合、認証はユーザーに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のインストールおよび構成を参照してください。
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リソースを構成するには、次の手順を実行します。
実際の認可を実行するOES認可ポリシーを作成します。
このポリシーは、OWSMによって提供された責任を使用して、実際の認可決定を行います。
さらにOWSMからOESに、認証されたサブジェクト、ターゲット・リソースおよびリクエストされたアクション、さらに認可リクエストで常に渡される暗黙属性のセット(詳細はOESポリシーでサポートされる属性タイプに関する項を参照)が渡されます。認可ポリシーでは、認可決定にこれらの値を使用できます。時間、日付などのOESの定義済属性も使用できます。
実際の認可用のOES認可ポリシーを作成するには、次の手順を実行します。
大まかな認可のための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リソース名をOWSMリソース名にマッピングする必要があります。OWSMからマスキング・コールを実行すると、リソース名がOESに渡されます。この名前はOESポリシーで定義されている名前と正確に一致する必要があります。
例として、次の特性を持つSOAP Webサービスをデプロイしたと仮定します。
デプロイしたアプリケーションの名前はHelloWorldServiceEar
です。
リソース・タイプは常にWS_SERVICE
です。
Webサービス名はHelloWorldService
です。
Webサービスのポート名はSayHelloPort
です。
Webサービス内の操作はsayHello
およびsayHelloBytes
です。
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 Access Manager with Oracle Security Token Service管理者ガイドの次の項に記載された用語、概念および構成情報をよく理解していることを前提としています。
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.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 Access Manager with Oracle Security Token Service管理者ガイドを参照してください。
Oracle Web Services Managerとともに使用するためのOAuth2の構成の詳細は、Oracle Fusion Middleware Oracle Access Management管理者ガイドのOAuthサービスの構成に関する項を参照してください。