ヘッダーをスキップ
Oracle® Fusion Middleware Oracle Web Services ManagerによるWebサービスの保護とポリシーの管理
12c (12.1.2)
E47994-03
  目次へ移動
目次
前
前 		 次
次		  

10 認可の構成

認可(アクセス制御とも呼ばれる)により、認証されたクライアントがどの操作にアクセスできるかを決定できます。

この章の構成は、次のとおりです。

10.1 認可の概要

多くの場合、ユーザーにWebサービスへのアクセスを許可するかどうかを決定する最初の手順は認証です。ユーザーが認証されたら、2番目の手順は、ユーザーがWebサービスへのアクセスを認可されていることを検証することです。これは、認可ポリシーを使用して実行されます。binding_authorization_templateまたはcomponent_authorization_templateアサーション・テンプレートを使用して、認可ポリシーを作成できます。

これらのテンプレートを使用して作成されたポリシーでは、ロール・ベースまたは権限ベースのアクセス制御(RBAC)が実行され、認証されたユーザーにWebサービスへのアクセスが許可されたいずれかのロールまたは権限が付与されていることが確認されます。

現在のリリースで使用可能な認可ポリシーのサマリーは、第3章「使用する事前定義済ポリシーの決定」の「認可ポリシー」を参照してください。第18章「事前定義済ポリシー」には、認可を実行するセキュリティ・ポリシーがまとめられ、ポリシーがトランスポート・レイヤーまたはSOAPヘッダーで実行されるかどうかが示されています。

認可の詳細は、『Oracle Web Services Managerの理解』の認可の概要に関する項を参照してください。


注意:

認可ポリシーは、サブジェクトが作成されている任意の認証ポリシーの後に続けることができます。

permitallおよびdenyallポリシーの両方を同じWebサービスにアタッチすることはできません。

10.2 保護するリソースの決定

認可ポリシーには、ポリシーで保護するリソースを指定するために使用できる次のプロパティがあります。すべての事前定義済ポリシーにすべてのプロパティを設定できるとはかぎりません。


注意:

事前定義済ポリシーは読取り専用であり、編集できません。ただし、ベースとして事前定義済ポリシーを使用して新しいポリシーを作成できます。新しいポリシーの作成の詳細は、「Webサービス・ポリシーの作成および編集」を参照してください。新しいポリシーを作成したら、必要に応じて、ポリシーの編集や設定の変更、または構成プロパティの設定が行えます。

10.3 認可権限の決定

概念的には、認証されたサブジェクトがWebサービス・ポリシーによって保護された特定のリソースへのアクセスを許可されるかどうかの決定には、連携して機能する2つの部分が関与します。

OPSSは、Webサービスの認可ポリシーの「アサーション」詳細ページを使用して、許可チェックが必要なリソースを決定します。認証されたサブジェクトがそのリソースに対してOPSSを介してWSFunctionPermission(または他の権限)を付与されている場合は、そのリソースへのアクセスが許可されます。


注意:

そのポリシーの構成プロパティ「権限チェック・クラス」を変更する場合は、ここでもカスタム・クラスを使用してください。

図10-1と図10-2に示す例をさらに検討します。

認可ポリシーの「アサーション詳細」ページで、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をユーザーまたはグループに付与した場合、この権限は、ドメインにデプロイされているすべてのアプリケーションに適用されます。

10.4 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#[オペレーション名]です。

少なくともname-space-of-webservice/service nameを含める必要があります。つまり、アスタリスク(*)ワイルドカードを使用して、すべてのアクションまたはすべてのリソースに権限を与えることはできなくなりました。

そのかわりに、単にオペレーション名を空白のままにしておくだけで、Webサービスのすべてのオペレーションを指定できます。たとえば、name-space-of-webservice/servicename#のようにします。

Permission Actionは常にinvokeです。

10.5 リクエスト元を指定するためのOracle HTTP Serverの構成

制約一致プロパティ設定には、リクエストが内部ネットワークまたは外部ネットワークから発行されたかどうかを指定するrequestOriginフィールドが含まれています。このプロパティは、Oracle HTTP Serverを使用しており、Oracle HTTP Server管理者がカスタムのVIRTUAL_HOST_TYPEヘッダーをリクエストに追加した場合のみ有効です。

リクエスト元を指定するためにOracle HTTP Serverを構成するには、管理者が次のようにhttpd.confファイルを変更する必要があります。

  1. mod_headersモジュールがロードされていることを確認します。

  2. 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ファイルに追加する必要もあります。

  3. Oracle HTTP Serverを再起動します。

  前
前 		 次
次
  目次へ移動
目次