| Oracle® Fusion Middleware Oracle Web Services ManagerによるWebサービスの保護とポリシーの管理 12c (12.2.1.3.0) E90181-03 |
|
 前 |
 次 |
| Oracle® Fusion Middleware Oracle Web Services ManagerによるWebサービスの保護とポリシーの管理 12c (12.2.1.3.0) E90181-03 |
|
|
前 |
次 |
トピック:
多くの場合、認証はユーザーに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リソースを構成するには、次の手順を実行します。
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リソース名をOWSMリソース名にマッピングする必要があります。OWSMから認可コールを実行すると、リソース名がOESに渡されます。この名前はOESポリシーで定義されている名前と正確に一致する必要があります。
例として、次の特性を持つSOAP Webサービスをデプロイしたと仮定します。
デプロイしたアプリケーションの名前はHelloWorldServiceEarです。
リソース・タイプは常にWS_SERVICEです。
Webサービス名はHelloWorldServiceです。
Webサービスのポート名はSayHelloPortです。
Webサービス内の操作はsayHelloおよびsayHelloBytesです。
OESリソースを構成するには、次の手順を実行します。
HelloWorldServiceEarです。実際の認可を実行するOES認可ポリシーを作成します。
OWSMからOESに、認証されたサブジェクト、ターゲット・リソースおよびリクエストされたアクション、さらに認可リクエストで常に渡される暗黙属性のセット(詳細はOESポリシーでサポートされる属性タイプに関する項を参照)が渡されます。
認可ポリシーでは、認可決定にこれらの値を使用できます。時間、日付などのOESの定義済属性も使用できます。
実際の認可用のOES認可ポリシーを作成するには、次の手順を実行します。
「リソースのマッピングと命名」で説明されているように、OESリソース名をOWSMリソース名にマッピングする必要があります。OWSMからマスキング・コールを実行すると、リソース名がOESに渡されます。この名前はOESポリシーで定義されている名前と正確に一致する必要があります。
例として、次の特性を持つSOAP Webサービスをデプロイしたと仮定します。
デプロイしたアプリケーションの名前はHelloWorldServiceEarです。
リソース・タイプは常にWS_SERVICEです。
Webサービス名はHelloWorldServiceです。
Webサービスのポート名はSayHelloPortです。
Webサービス内の操作はsayHelloおよびsayHelloBytesです。
OESリソースを構成するには、次の手順を実行します。
HelloWorldServiceEarです。事前定義済の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からユーザー名が構成されます。 |
OAuth2クライアントAPI機能により、RESTクライアントを作成せずにアクセス・トークンを取得できます。APIのコンシューマはアクセス・トークンをフェッチし、任意のアウトバウンド・リクエストで使用できます。API呼出し元がこのOAuth2アクセス・トークンを使用し、OAuth2 Authサーバーで保護されているOAuth2リソース・サーバーのサービスをコールできます。
アクセス・トークンを取得するために認証および認可するOAuth2サーバーを起動します。
アクセス・トークンを使用してリソース・サーバーへのメッセージを保護します。
OWSMは、前述の機能を個別に実行できません。このOAuth2クライアントAPI機能を使用して、アクセス・トークンを取得するために認証および認可する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サービスの構成に関する項を参照してください。
Weblogicドメインに複数のアプリケーションが存在するため、各アプリケーションに異なる一般ユーザーが割り当てられます。
http_oauth2_token_with_resource_owner_creds_client_policy
http_oauth2_token_with_resource_owner_creds_over_ssl_client_policy.
クライアント側のOAuthポリシー - grant_type (そのデフォルト値/欠落は、grant_typeがclient_credentialsであることを意味します)には、新しい構成オーバーライドが含まれます。
オーバーライド・プロパティでgrant_typeを追加します。これらのポリシーで、grant_typeがパスワードに設定されます。
注意:
grant_typeがパスワードの場合、csf-keyを使用してoauthサーバーへのリクエストのヘッダーでユーザー名とパスワードが設定されます。基本認証フローを使用したリソース所有者パスワード資格証明の割当て
JWT Bearerフローを使用したリソース所有者パスワード資格証明の割当て
ポリシーのアタッチおよびプログラムによる構成オーバーライドの指定
WLSTからのOAuth構成ポリシーのアタッチ
EMからのOAuth構成ポリシーのアタッチ
注意:
リソース所有者パスワード資格証明の付与タイプは、デバイス・オペレーティング・システムや強い権限を持っているアプリケーションなど、リソース所有者がクライアントと信頼関係にある場合に適しています。認可サーバーではこの付与タイプを有効化する際に特に注意し、他のフローが実行可能でない場合にのみ許可する必要があります。OWSMはOAuthベースの匿名ユーザー・アクセスをサポートしています。
注意:
匿名APIは公開されていませんが、認証ヘッダーにアクセス・トークンを必要とします。OAuthベースの匿名ユーザー・アクセスをサポートするために、OWSMにはポリシー・プロパティenable_anonymous_client_atがあります。トークンのclient_id値とsub値が同じである場合、Identity Cloud Serviceにユーザーが存在しない場合でも、このプロパティはサブジェクトを匿名として確立します。
値がtrueの場合、この構成オーバーライドenable_anonymous_client_atは、Identity Cloud Serviceからのクライアント・アクセス・トークンを匿名トークンとして使用します。ポリシーのデフォルト値はfalseで、この構成をtrueに設定することで有効化されます。構成がtrueに設定されている場合、OWSMはユーザーを匿名で認証し、Identity Cloud Serviceクライアント・アクセス・トークンが検証された後、匿名サブジェクトを作成します。
enable_anonymous_client_atプロパティがあります。oracle/http_jwt_token_over_ssl_service_policy oracle/http_jwt_token_service_policy oracle/http_oam_token_service_policy oracle/multi_token_cg_sso_over_ssl_rest_service_policy oracle/multi_token_cg_sso_over_ssl_rest_service_policy oracle/multi_token_cg_sso_rest_service_policy oracle/multi_token_cg_sso_rest_service_policy oracle/multi_token_over_ssl_rest_service_policy oracle/multi_token_over_ssl_rest_service_policy oracle/multi_token_rest_service_policy oracle/multi_token_rest_service_policy oracle/multi_token_sso_over_ssl_rest_service_policy oracle/multi_token_sso_over_ssl_rest_service_policy oracle/multi_token_sso_rest_service_policy oracle/multi_token_sso_rest_service_policy
multi_tokenポリシー内のJWTおよびOAMアサーションには、enable_anonymous_client_at構成オーバーライドがあります。
次に、WLSTを使用してポリシーをアタッチし、構成オーバーライドを変更する例を示します。
beginWSMSesion()
createWSMPolicySet('rest-resource-policy-set', 'rest-resource','Domain("*")')
attachWSMPolicy('oracle/multi_token_rest_service_policy')
commitWSMSession()
beginWSMSession()
selectWSMPolicySet('rest-resource-policy-set')
setPolicySetPolicyOverride('oracle/multi_token_rest_service_policy', 'enable_anonymous_client_at', 'true')
commitWSMSession()
有効な信頼証明書がトラスト・ストアにインポートされると、OWSMはOAuthトークンを検証します。
複数のテナントをサポートするシナリオでは、すべてのテナント(作成済またはまだ作成されていない)の信頼証明書をトラスト・ストアにインポートするか、検出機能を使用して、OAuthトークンを検証します。
検出機能は、OWSMがIdentity Cloud Service (IDCS)から必要な信頼証明書をフェッチし、これを使用してOAuthトークンを検証するのに役立ちます。検出機能を使用し、REST APIを使用してグローバル・レベルで信頼を設定します。すべてのテナントがグローバル情報を使用して信頼を設定します。
IDCSの場合、グローバル検出情報にテナント情報は含まれず、テナントのJWK/検出情報にアクセスするために使用されます。
注意:
単一インスタンス環境で複数のテナントの検出機能をサポートする要件は、各テナントが独自のデータベースを持つ、階層化されたマルチテナント・シナリオとは異なります。
関連項目:
グローバル検出構成のインポートおよび信頼ドキュメント名の構成のエクスポートを行うREST APIメソッドについては、『Oracle Web Services Managerでの資格証明およびキーストアの管理のためのREST API』のトークン発行者の信頼構成の管理に関する項を参照してください。
OWSMは、Google OAuth2サーバーおよびTwitter OAuthサーバーなどのサード・パーティ・サーバーと統合されます。
この項では、OWSM統合を使用可能にする方法について説明します。
OWSMはtwitterに統合されます。TwitterではOAuth1を使用して、認可アクセスをAPIに提供します。
REST APIは、Twitterデータの読取りおよび書込みを行うプログラムによるアクセスを提供します。新しいTweetを作成し、作成者プロファイルおよびフォロワ・データなどを読み取ります。REST APIは、OAuthを使用してTwitterアプリケーションおよびユーザーを識別します。レスポンスをJSONで取得できます。
OWSMは、OWSMのOAuth 1.0プロトコルの部分サポートを提供してOAuth1タイプのアクセス・トークンおよびトークン・シークレットを使用してTwitter APIへのリクエストを保護する必要がある単一ユーザーのOAuthユースケースをサポートします。この場合、アクセス・トークンを操作してTwitterリソースの署名付きリクエストを行うポイントからです。
OWSMでは、静的に生成されたコンシューマおよびアクセス・トークンを使用してアプリケーションによるTwitter APIの使用を許可する新しいOAuth1クライアント・ポリシーを提供します。アクセス・トークンの取得はOWSMポリシーによって行われません。
Twitterアカウントを構成する前提条件
OWSMと統合するTwitterアカウントの構成
Twitterでは、現在ほとんどの認証方式にOAuth1プロトコルを使用しています。OAuth2 Bearerトークンは、アプリケーション専用認証にのみサポートされます。OWSMのOAuth1プロトコルの部分サポートを提供してOAuth1タイプのアクセス・トークンおよびトークン・シークレットを使用してTwitter APIへのリクエストを保護する必要がある単一ユーザーのOAuthユースケースに焦点を当てます。
OAuthを使用するには、アプリケーションで次を実行する必要があります。
ユーザー・アカウントのかわりに操作するアクセス・トークンを取得します。
アクセス・トークンを使用してTwitterのAPIに送信するすべてのHTTPリクエストを認可します。
Twitterアカウント設定
アクセス・トークンを取得した後、twitterアカウントを構成できます。次の手順に従って、メッセージをツイートするRESTアプリケーションを作成および実行します(ステータスを更新します)。
https://twitter.com/でTwitterユーザー・アカウントを作成します。
このアカウントを使用して、https://apps.twitter.comに移動します。
「Create New App」をクリックして、新しいアプリケーションを作成します。すべての詳細を入力します。
アプリケーションをクリックします。
タブ「Key and Access Tokens」をクリックします。
コンシューマ・キーおよびシークレット、アクセス・トークンおよびシークレットを生成します。
後で必要になるため、4つのすべてのキー - コンシューマ・キー、コンシューマ・シークレット、アクセス・トークン、アクセス・トークン・シークレットをメモします。
資格証明の構成
コンシューマ・キーおよびコンシューマ・シークレットの値を保持するCSFキーを作成します。
例: updateCred(map="oracle.wsm.security", key="basic.client.oauth1.credentials", user="NMugHF4zz3ywchygNsXHy", password="XhcrhgVzAHWmerW4JN20xLrv3FliwlbIYPqTnbntUyY9wB", desc="Twitter account consumer key")
アクセス・トークンおよびアクセス・トークン・シークレットの値を保持するCSFキーを作成します。
例: updateCred(map="oracle.wsm.security", key="basic.token.oauth1.credentials", user="778014527828787200-3e7LqGPB79ve0Bbo8Z0acvl7op2", password="ZAVO3BsBNxGMsR7kwGeX3efhqQ2psQvcdvuLLCYXb", desc="Twitter account access token")
トラストストアの構成
Twitter SSL証明書をキーストアにインポートする必要があります
twitter SSL証明書をローカル・ファイルにエクスポートします。これをtwitter.crtと呼ぶことにします。ブラウザを使用して、SSL証明書をエクスポートできます。たとえば、Firefoxを使用している場合、次のようにエクスポートできます。
下部のtop / PadlockでSSL証明書アイコンをクリックします。
「Details」タブをクリックします
階層から使用する証明書を選択します[図で囲まれていない]
「Export」をクリックします
keytool -import -keystore client-truststore.jks -storepass changeit -file twitter.crt
JDeveloperを使用したRESTfulクライアントの作成
Twitter OAuthサーバーとの統合をテストするには、OWSM OAuth1 Twitterクライアント・ポリシーを使用してTwitter APIのいずれかを起動するWebアプリケーションを作成する必要があります。ここで提供されているサンプルでは、https://api.twitter.com/1.1/statuses/update.json URLでTweet APIにアクセスします。
クライアント・アプリケーションを作成するには、次の手順を実行します。
JDeveloperを起動します。
新規アプリケーションおよびプロジェクトの作成
前述で作成した新しいプロジェクトを右クリックして、新しいHTTPサーブレットを選択します(表示されていない場合、「ギャラリ」メニューの「新規」から、「Web層」、「サーブレット」、「HTTPサーブレット」の順に選択します)。
次のコード・ブロックで示されているコンテンツを使用して、この新しいサーブレットを編集します。
必要に応じて、必要なOWSMおよびJERSEYライブラリを追加します。
プロジェクトを保存し、すべてのインポートが解決され、ビルドの問題がないことを確認します。
WebアプリケーションをWLSサーバーにデプロイします。プロジェクトを右クリックし、「デプロイ」、「webapp」の順に選択します。JDEVで構成している場合はアプリケーション・サーバーに直接デプロイし、そうでない場合はWARファイルにデプロイし、WLSコンソールを使用してこのWARファイルを手動でデプロイします。
ブラウザからwebappをテストします。ブラウザに出力される他のメタデータとともにTwitter APIからステータス200を受け取ります。アカウントwww.twitter.comにログインし、OWSMポリシーを使用して送信したツイートを監視できます。
OWSM OAuth2クライアントは、Google OAuth2クライアントのSSLポリシーを使用して、Google OAUTH2サーバーと統合できます。Google APIでは、アクセスを必要とするクライアント・アプリケーションを認証および認可するOAuth 2.0プロトコルを使用します。
OWSMの場合、Google OAuth 2.0は、サーバー・アプリケーションとGoogle APIのサーバー間相互作用をサポートします。これは、サーバー・アプリケーションがJWTトークンを送信してOAuthサーバーからアクセス・トークン(AT)を取得し、そのATを使用してGoogle APIにアクセスする2-legged OAuth2シナリオです。このシナリオでは、個別のエンド・ユーザーではなくアプリケーションに属するアカウントであるサービス・アカウントが必要です。クライアント・アプリケーションでは、ユーザーではなくサービス・アカウントのかわりにGoogle APIを起動します。
Googleサービス・アカウントの作成
Googleサービス・アカウントを構成してOWSMクライアントとGoogle OAUTH2サーバーを統合する必要があります。
注意:
失われた場合に再生成できないため、マシンにGoogleが生成した秘密/公開鍵を記録します。
再表示されないため、秘密鍵のパスワードを記録します。
アクセス・トークン・リクエストおよびレスポンス
Google APIにアクセスするGoogle認可サーバーからのクライアント・アプリケーション・リクエスト・アクセス・トークン。
単一のアクセス・トークンは、複数のAPIへの様々なアクセスを付与できます。スコープという変数パラメータは、アクセス・トークンが許可するリソースおよび操作のセットを制御します。アクセス・トークン・リクエスト中に、アプリケーションはスコープ・パラメータの1つ以上の値を送信します。
アプリケーションがユーザーを偽装する前にこのタイプの偽装を実行する権限を付与する必要があり、通常ドメイン管理者によって処理されます。ドメイン管理の詳細は、APIクライアント・アクセスの管理を参照してください。
OAUTH2サーバーがクライアントのリクエストを正常に検証してから、クライアントは取得したレスポンスからアクセス・トークンを抽出し、トークンをアクセスする必要があるGoogle APIに送信します。トークン・リクエストのスコープに示されている操作およびリソースのセットにのみ、アクセス・トークンが有効です。
注意:
アクセス・トークンの有効期限の処理: 一度取得したアクセス・トークンは有効期限が切れるまでキャッシュされます。有効期限が切れると、OWSMは別のアクセス・トークンを自動的に取得し、有効期限が切れるまでキャッシュします。必要な資格証明を使用して、Google Developers Consoleにログインします。
Google API Managerページの「Overview」をクリックします。
「Enabled APIs」タブをチェックして、アクセスするAPIがすでに有効化されているかどうかを確認します。有効でない場合、「Google APIs」タブに移動して、探しているAPIを検索します。
必要なAPIをクリックして、上部の「Enable」ボタンをクリックします。
「Enabled APIs」タブに戻って、新しく有効化したAPIがリストに表示されていることを確認します。
keytoolユーティリティを使用して、PKCS#12キーストア(このキーストアは、Googleサービス・アカウントの作成後に取得されます)をJKSキーストアにインポートします。
keytool -importkeystore -srckeystore <location of the .p12 file>-srcstoretype PKCS12 -destkeystore <OWSM keystore location> -deststoretype JKS
srcおよびdestキーストア・パスワードを入力します。(ヒント: srcパスワードは、Google Service Accountの作成後に書き留めたものです。エントリがキーストア「privatekey」に追加されたことを確認します。
キーストアのコンテンツを表示するためにkeytool -listコマンドを使用します。
keytool -keystore <OWSM keystore location> -list
importKeyStoreスクリプトを使用してキーストアから1つ以上の別名をインポートするには、WLSTを使用します。[userx@hostname bin]$ ./wlst.sh
Initializing WebLogic Scripting Tool (WLST) ...
Welcome to WebLogic Server Administration Scripting Shell
Type help() for help on available commands
wls:/offline> connect("weblogic","password","t3://myhost.example.com:8001")
Connecting to t3://myhost.example.com:8001 with userid weblogic ...
Successfully connected to Admin Server "jrfServer_admin" that belongs to domain "jrfServer_domain".
Warning: An insecure protocol was used to connect to the server.
To ensure on-the-wire security, the SSL port or Admin port should be used instead.
wls:/jrfServer_domain/serverConfig/> svc = getOpssService(name='KeyStoreService')
wls:/jrfServer_domain/serverConfig/> svc.importKeyStore(appStripe='owsm', name='keystore', password='password', aliases='privatekey', keypasswords='notasecret', type='JKS', permission='true', filepath='<OWSM keystore location>')
ここで示されている手順に従って、cwallet.ssoに新しい資格証明(google-service-credentialなど)を作成します。資格証明の名前は、Googleサービス・アカウントの作成後に生成されるサービス・アカウントの電子メールIDです。パスワードは問いません。
