1. RESTのためのSODA開発者ガイド
  2. セキュリティ

6 セキュリティ

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

この項を読む前に、ORDSのセキュリティ機能に精通している必要があります。

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はアプリケーション・サーバー・ロールです。

関連項目:

ORDSのセキュリティ機能の詳細は、Oracle REST Data Servicesインストレーション、構成および開発ガイドを参照してください

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

6.1 認証メカニズム

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

関連項目:

『Oracle REST Data Servicesインストレーション、構成および開発ガイド』

親トピック: セキュリティ

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

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

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

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

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

また、ords.war userコマンド使用して特定のロールを持つテスト・ユーザーを作成できます。この例では、プレースホルダ<user_name>と<password>を適切なユーザー名と<password>に置き換えています。 

# Create a user with role SODA Developer.
# (Be sure to replace placeholder <user_name> here.)
java -jar ords.war user <user_name> "SODA Developer"

# Access the JSON document store using basic authentication.
# (Be sure to replace placeholders <user_name> and <password> here.)
curl -u <user_name>:<password> https://example.com/ords/scott/soda/latest/

親トピック: セキュリティ