6 セキュリティ

RESTのためのSODAなどのORDSでは、サービスを保護するためにロールベースのアクセス制御が使用されます。ここでは、RESTのためのSODAに必要なロールおよび権限について説明しています。

この項を読む前に、ORDSのセキュリティ機能に精通している必要があります。関連する情報は、『Oracle REST Data Servicesインストレーション、構成および開発ガイド』を参照してください。

REST SODAを使用する前に、データベース・ロールSODA_APPをデータベース・ユーザーに付与する必要があります。さらに、ords.enable_schemaを使用してORDSでスキーマを有効にする際に、アプリケーション・サーバー・ロールSODA Developerを持つユーザーのみがサービスにアクセスできるように、権限が作成されます。具体的には、ords.enable_schemaは次の権限マッピングを作成します。

exec ords.create_role('SODA Developer');
exec ords.create_privilege(p_name => 'oracle.soda.privilege.developer',
                           p_role_name => 'SODA Developer');
exec ords.create_privilege_mapping('oracle.soda.privilege.developer', '/soda/*');

このことは、デフォルトで、JSONドキュメント・ストアにアクセスするにはユーザーはアプリケーション・サーバー・ロールSODA Developerを持っている必要があることに影響します。

カスタムの権限マッピングを追加することもできます。次に例を示します。

declare
  l_patterns owa.vc_arr;
begin
  l_patterns(1) := '/soda/latest/employee';
  l_patterns(2) := '/soda/latest/employee/*';
  ords.create_role('EmployeeRole');
  ords.create_privilege(p_name      => 'EmployeePrivilege',
                        p_role_name => 'EmployeeRole');
  ords.create_privilege_mapping(p_privilege_name => 'EmployeePrivilege',
                                p_patterns       => l_patterns);     
  commit;
end;

この例では、EmployeeRoleロールを持つユーザーのみがemployeeコレクションにアクセスできるように指定する権限マッピングを作成します。

複数の権限パターンが同じリソースに適用された場合、最も具体的なパターンを持つ権限が他の権限よりも優先されます。たとえば、パターン/soda/latest/employees/*および/soda/*は、どちらもリクエストURL http://example.org/ords/quine/soda/latest/employee/id1と一致します。

'/soda/latest/employees/*'は'/soda/*'よりも具体的であるため、EmployeePrivilege権限のみがこのリクエストに適用されます。

注意:

SODA_APPはOracle Databaseロールです。SODA Developerはアプリケーション・サーバー・ロールです。

トピック

6.1 認証メカニズム

ORDSは、様々な認証メカニズムをサポートしています。JSONドキュメント・ストアRESTサービスは、サーバー間の相互作用に使用されることを意図しています。このため、JSONドキュメント・ストアRESTサービスで使用する認証メカニズムとしては、Two-Legged OAuth(クライアント資格証明フロー)をお薦めします。しかし、HTTP Basic認証など、その他のメカニズムもサポートされています。

6.2 開発およびテストのセキュリティ上の考慮事項

開発およびテストのセキュリティ上の考慮事項を示します。

次のように、デフォルトの権限マッピングを削除することで、セキュリティを無効にし、匿名アクセスを許可できます。

exec ords.delete_privilege_mapping('oracle.soda.privilege.developer', '/soda/*')

しかし、本番システムで匿名アクセスを許可することはお薦めしません。匿名アクセスの許可は、認証されていないユーザーに任意のコレクションの読取り、更新、またはドロップを許可することになります。

また、ords.war userコマンド使用して特定のロールを持つテスト・ユーザーを作成できます。次に例を示します(new_passwordは、ユーザーbobのパスワードのプレースホルダです)。

# Create user bob with role SODA Developer
java -jar ords.war user bob "SODA Developer"

# Access the JSON document store as user bob using basic authentication
curl -u bob:new_password https://example.com/ords/scott/soda/latest/