データへのアクセスの制御

アプリケーションのセキュリティに関しては、認証と権限のコンセプトが重要な役割を果たします。

ビデオを視聴して、認証および権限の概要を把握します。

アプリケーションにまだ権限が設定されていません。つまり、現在、制限はなく、すべての要求にアプリケーション全体へのフルアクセス権があります。このレッスンでは、アプリケーションへのアクセスを制限する方法について学習します。

本稼働環境では、制限が設定されていない場合でも、デフォルトですべてのエンドポイントが認証されます。認証方法は自由にカスタマイズできる。便宜上、ほとんどの一般的なシナリオに対応するために、即座に利用可能な一連の認証方法がサポートされています。業務上の理由でオープンエンドポイントを匿名ユーザに公開する必要がある場合は、追加の措置を講じる必要があります。本稼働環境での認証の設定については、このコースでは説明しません。

前述のとおり、開発環境でアプリケーションをテストする場合、認証は必要ありません。テスト環境の認証を設定する方法を後で確認します。

以下では、ビジネスデータへのアクセスをきめ細かいレベルで制御するために使用できるアノテーションについて説明します。説明したアノテーションは、サービスが定義されている .cds ファイルに直接挿入できます。この例では、CatalogService のファイル cat-service.cds と AdminService のファイル admin-service.cds になります。

ただし、実際のサービス定義から分離するために、権限アノテーションを異なる .cds ファイルに保存することをお奨めします。これにより、実際のサービス定義が簡潔になり、構造にのみ焦点を当てられます。また、権限モデルに所有権とライフサイクルを分離させることもできます。

このベストプラクティスに従い、個別の .cds ファイルを作成して CatalogService と AdminService のアクセスルールをモデル化します。これらのファイルはそれぞれ cat-service-auth.cds および admin-service-auth.cds と呼ばれ、サービス定義のファイルと同様に、プロジェクトの srv フォルダに保存されます。

最初に、CatalogService へのアクセスの制御に使用する cat-service-auth.cds ファイルを見てみましょう (以下の図を参照)。

このファイルでは、Authors および Books エンティティの定義と、usingディレクティブを介したCatalogService モデルからの submitOrder アクションの定義をインポートします。

すべてのユーザのアクセスを読み取り専用アクセスに制限するために、Authors および Books エンティティには、annotate ディレクティブを介して @readonly というアノテーションが付けられます。

アクセス制御の基礎として、アプリケーション固有のコンセプトロールを設計することができます。ユーザは、プラットフォームの権限管理ソリューションで管理ユーザによって割り当てられる複数のロールを持つことができます。

CAP では、アプリケーション固有のユーザロールに加えて、事前定義されたいわゆる疑似ロール (authenticated-user など) もサポートされています。このロールは、正常に認証されたユーザを参照します。

この例では、@requires アノテーションを使用して、認証されたユーザのみが submitOrder アクションを実行できることを制御します。

次に、AdminService のアクセス制御を含む admin-service-auth.cds ファイルを見てみましょう (以下の図を参照)。

ここでも、最初に using ディレクティブを使用して、アノテーションを付ける定義 (Authors および Books Entity) を AdminService モデルからインポートします。

Authors エンティティには、@(requires: 'admin') のアノテーションが付けられます。これにより、アプリケーション固有の管理者ロールを持つユーザのみが作成者エンティティにアクセスできることが決定されます。

ブックエンティティの権限を定義するには、アノテーション @restrict を使用します。これは、アプリケーション固有の管理者ロールを持つユーザのみが Books エンティティで READ、CREATE、および UPDATE 操作を実行できるように指定します。DELETE 操作は、管理者ロールを持つユーザに対してのみ許可され、ストックが 0 のブックのみを削除できるという追加制約があります。

@restrict アノテーションでは、任意の数の権限オブジェクトを含む配列が提供されます。これにより、各権限オブジェクトの構造は以下のようになります。

1
{ grant: <events>, to: <roles>, where: <filter-condition> }

権限オブジェクトのプロパティは、以下のように定義されます。

• grant

  権限が適用される 1 つ以上のイベント (READ、CREATE、UPDATE、DELETE など)

• to

  権限が適用される 1 つ以上のユーザロールまたは疑似ロール (オプション)

• where

  インスタンスレベルでアクセスをさらに制限するフィルタ条件 (オプション)

少なくとも 1 つの権限が満たされている場合、要求は権限の配列で構成される制限を渡します。

これで、アノテーションを使用して権限を定義する方法を確認できました。次に、認証について説明します。ユーザの正常な認証は、権限チェックを実行するための基礎となります。

CAP は、多数の事前構築済み認証方針とともに出荷されます。

本稼動では、jwt 認証方針がデフォルトで使用されます。ユーザ ID、割り当てられたロールおよびユーザ属性は、実行時に User Account and Authentication (UAA) サービスのバインドされたインスタンスによって提供されます。これは、受信 HTTP 要求の Authorization ヘッダの JWT トークンの形式で行われます。

開発時には、認証方針 mocked がデフォルトで使用されます。この認証方針では、事前定義されたモックユーザによる Basic 認証が使用されます。オプションで、以下の図に示すように、package.json ファイルを使用して追加のユーザを定義できます。

1
cds env get requires.auth

モックされた認証では、Basic 認証が使用されます。そのため、要求で認証方式 Basic 付きの Authorization ヘッダをテスト目的で使用することができます。認証情報は、以下の例に示すように <user>:<password> の形式で指定されます。

12
GET <service_url>/Books
Authorization: Basic catuser:abcd1234

CDS モデルに制限を追加する方法については、ビデオを視聴してください。