LoginSignup
3
1
お題は不問!Qiita Engineer Festa 2023で記事投稿!

Amplifyを利用したマルチテナント対応を考えてみる

Last updated at Posted at 2023-07-20

はじめに

Amplifyを利用して簡単にWebアプリを作ってみる で作成したアプリに対して、よりサービス利用を意識した拡張を加えていこうと思います。
今回はマルチテナント対応の一環として、自身が所属するテナントのデータのみ操作できるように認可制御をかけていきます。

本対応を行うことで、以下が実現できます。

  1. AWS Cognitoを用いた認証およびテナントIDの取得
  2. AWS AppSyncとVTLを用いたテナント毎のデータ操作を可能にする認可制御

アーキテクチャ

  • Frontend: Next.js v12
  • 認証: AWS Cognito
  • バックエンド: AppSync & DynamoDB
    amplify.jpg

前提条件

Amplifyを利用して簡単にWebアプリを作ってみる の手順に沿って、アプリを作成済みであること。

データ所有者のみデータの参照と変更を許可する場合

  1. Amplifyのドキュメント に記載されているように、authディレクティブをTodoスキーマに対して追加する。
    schema.graphqlを以下コードで上書きしてください。
    amplify/backend/api/nextamplified/schema.graphql
    type Todo
      @model
      @auth(rules: [{ allow: owner, provider: userPools }]) {
      id: ID! @primaryKey
      description: String!
    }
    
  2. amplify pushを実行して変更を反映する。
    amplify push
    

動作確認

  1. Next.jsのアプリを起動して、動作を確認する。

    npm run dev
    
  2. ブラウザで http://localhost:3000/ にアクセスする。

  3. Create Accountを選択 -> ユーザ名、パスワード、メールアドレスを入力して異なるアカウントを2つ作成する。

  4. 一つ目のユーザでサインインする。
    image.png

  5. Todo内容を入力後、「Todo追加」ボタンを押して、Todoリストに登録されたことを確認する。
    image.png

  6. サインアウトボタンをクリックして、サインアウトしてから先ほど作成した二つ目のユーザでサインインする。

  7. Todoリストに一つ目のユーザで登録したTodoが表示されていないことが確認できる。
    image.png

それぞれのユーザが登録したデータが所有者のみ参照できることが確認できました。AWS Amplifyはこれをどのように実現しているのでしょうか?
実は、先ほどのauthディレクティブに owner を指定したことで、DynamoDBのテーブル上にownerというフィールドが自動で登録されるようになり、AppSyncがownerの値を元にフィルタしたレコードのみをレスポンスとして返すように処理が変更されるようになっています。
image.png

実際のユースケースではユーザに付与した権限であったり、所属しているグループなどによって認可制御を行うケースもあると思います。
今回の記事では、特定のテナントが登録したデータを異なるテナントからは参照・更新できないように発展させてみようと思います。

所属するテナントのデータのみ参照・変更を許可する場合

Cognitoのユーザに対する設定追加

  1. AWS管理コンソールから、Amazon Cognito -> サインアップエクスペリエンスのカスタム属性を追加をクリックする。
    image.png

  2. 名前に tenantId を入力して、変更を保存をクリックする。
    これでユーザーに持たせるカスタム属性として、テナントIDが追加できるようになりました。続けてそれぞれのユーザーに対してカスタム属性を追加していきます。
    image.png

  3. Amazon Cognito -> ユーザー からユーザーを選択して、ユーザー属性の編集ボタンをクリックする。

  4. オプションの属性として、 custom:tenantIdを追加して、tenant1を入力して変更を保存をクリックする。
    image.png

  5. 同様にもう一つのユーザーにもcustom:tenantIdを追加して、tenant2を入力して変更を保存をクリックする。
    (※2つのユーザーがtenantIdに異なる値を持っていることを確認する)
    ここまででCognitoに対する設定は完了です。今回は手動でカスタム属性を登録しましたが、実際にはユーザーを作成する際の処理の一部でtenantIdを登録する形がよいでしょう。

スキーマの更新

  1. schema.graphqlの中身を以下で上書きする
    新しいフィールドとしてtenantIdを追加しています。
    amplify/backend/api/nextamplified/schema.graphql
    type Todo
      @model
      @auth(rules: [{ allow: private, provider: userPools }]) {
      id: ID! @primaryKey
      description: String!
      tenantId: String!
    }
    

VTLを用いたマルチテナントでの認可制御

残念ながら2023/07/20時点では、先ほど紹介したauthディレクティブを用いてCognitoのカスタム属性の値を元にAppSyncで認可制御を行うことはできないというのが調査した結論です。
(Cognitoグループによる認可制御はできるのですが、Cognitoグループは管理者や閲覧者などのロールを表すために利用したかったので、自身が所属するテナントを表すためにはどうしてもカスタム属性が必要だった)

そのため複雑になってしまいますが、AppSyncが提供しているVTLによる処理をオーバーラードすることでCognitoのカスタム属性を用いて、取得したtenantIdでデータをフィルタするようにしてみます。

AppSyncはApache Velocityによるテンプレートプログラミングを用いることで、GraphQLのクエリをパースしてDynamoDBへのクエリに変換し、データの参照や更新を行うバックエンドの処理を実現しています。
これらのVTLコードは、AWS Amplifyを利用することで自動生成されます。今回はそのコードをCustom Resolverにオーバーライドする方法に沿って、認証後の処理を追加します。

  1. 下記VTLコードをamplify/backend/api/nextamplified/resolvers配下に配置する。

    amplify/backend/api\nextamplified/resolvers/Query.listTodos.postAuth.1.req.vtl
    #if( !$ctx.stash.get("hasAuth") )
        $util.error("hasAuth")
    #end
    
    #set($tenantId = $context.identity.claims.get("custom:tenantId"))
    
    ## tenantIdの存在チェック
    #if( $util.isNullOrEmpty($tenantId) )
        $util.error("no tenantId claim")
    #end
    
    ## フィルタにtenantIdを追加
    #if($ctx.stash.fieldName.startsWith("list"))
        #set( $filter = {"tenantId": {"eq": $tenantId}} )
        $util.qr($ctx.stash.put("authFilter", $filter))
    #end
    
    $util.toJson({})
    
  2. amplify pushを実行してスキーマとVTLの変更を反映する。

    amplify push
    

動作確認

  1. AWS管理コンソールからAppSync画面に移動して、APIの中からnextamplified-devを選択する。
    image.png

  2. メニューからクエリを選択し、以下のクエリを入力する

    mutation MyMutation {
      tenant1_1: createTodo(input: {description: "Todo 1", tenantId: "tenant1"}) {
        id
      }
      tenant1_2: createTodo(input: {description: "Todo 2", tenantId: "tenant1"}) {
        id
      }
      tenant2_1: createTodo(input: {description: "Todo 3", tenantId: "tenant2"}) {
        id
      }
    }
    
    query MyQuery {
      listTodos {
        items {
          tenantId
          id
          description
        }
      }
    }
    
    

    スクリーンショット 2023-07-20 100853.png

  3. 「ユーザープールでログイン」をクリックして、Cognitoのユーザー名とパスワードを入力してログインする。
    スクリーンショット 2023-07-20 095658.png

  4. 「実行する」をクリックして、MyMutationを選択するとレコードがTODOテーブルに挿入される。

  5. 「実行する」をクリックして、MyQueryを選択すると右ペインにtenant1のデータ2件が表示されていることが確認できる。
    image.png

  6. ログアウトのボタンをクリックして、もう一つの方のユーザでログインし直す。

  7. 「実行する」をクリックして、MyQueryを選択すると右ペインにtenant2のデータ1件のみ表示されていることが確認できる。
    image.png

テナントIDと合致するデータのみ参照できることが確認できました。
同様のやり方で、VTLコードを用意すればGraphQL Mutationの方もtenantIdによる認可制御をかけることができます。
本当はフロントアプリを軽く修正して動作するだろうと見込んでいたのですが、アプリからだとVTL処理でなぜか上手くtenantIdが取れず断念しました。。
(時間があったら後日確認します)

感想

AWS Amplifyを使って権限が与えられているデータのみ操作する方法を説明してきました。

  • AWS AmplifyはAWSのインフラとアプリの両方を理解していないと実装が難しく、ローコード開発という点ではこれからの技術かなと思いました。AWSを今までよく使っている方であればAmplifyの親和性は高く、AWSのベストプラクティスに沿って自動化されているのでそれなりに安心して利用できると思いました。(Amplifyを通して、AWSの裏の構成や仕組みを理解するのは勉強になりました。)
  • AWSマネージドサービスが使われているので、拡張性、耐障害性、従量課金によりコストが抑えられるといったメリットが享受できるアプリであれば導入を検討してみるのも良いかと思います。
  • 最初は覚えることが多く学習コストが高いのと、AWSインフラとアプリ含めて見ていかなければいけないのでメンテナンス性は落ちるかなという印象です。。
3
1
0

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
3
1