サーバーワークスの村上です。
Difyで作成したアプリをWebアプリとして公開すると、基本的にはURLを知っている人は誰でも利用できる仕様です。URLはランダムな文字列を含むため、それで問題ないケースもありますが、扱うデータによってはIP制限や認証機能を実装したいケースも想定されます。
そこでタイトルのとおり、Difyで公開したWebアプリに認証機能を実装してみます。利用イメージとしては、Difyのアプリにアクセスすると、既存の認証基盤（今回はkeycloakを利用）にリダイレクトされ、認証を経た後アプリが表示されるものになります。
結論
まずは本ブログの要旨です。
- Difyアプリの公開は、URLを共有すればすぐ使える反面、そのままだとURLを知っている人は誰でも利用できる
- Application Load Balancer（ALB）のユーザー認証機能を利用すれば、公開したアプリに認証機能を実装できる
- 認証基盤には既存のIdpを流用できる
Difyとは
LangGenius社が提供している、生成AIアプリケーションを作成するためのオープンソースプラットフォームであり、どなたでも利用することが可能なソフトウェアです。
弊社ブログに多くのDify関連ブログがありますのでご参考ください。
構成
Dify on AWSの構成はすでにAWSがサンプルを出しており、今回はdify-self-hosted-on-awsを使用しています（CloudFrontは利用なし）。
さらに、以下の実装を追加しています。
- ALBのユーザー認証機能を利用し、Amazon Cognitoによる認証を実装
- すでに利用中の認証基盤があることを想定し、Amazon Cognitoユーザープールにはユーザーを作成せず、KeycloakをSAML連携
- ALBのリスナールールを編集し、公開アプリのパスの1つ
/chat/*に認証アクションを追加
利用イメージ
デフォルトでは冒頭に記載したとおり、公開したWebアプリのURLにアクセスすると、直接アプリの画面に遷移します。
今回の追加実装をすると、まずAmazon Cognitoの画面にリダイレクトします。
次にSAML連携したIdpの認証画面に遷移します。
認証後、Webアプリの画面が表示されます。
実装上の留意点
リスナールールについて
今回は公開したチャットフローのWebアプリに対してのみ認証を追加したいため、/chat/*のパスベースルーティングのルールに認証を追加しました。その他のパス、例えば管理コンソールへのアクセスには設定していません。※管理コンソールへのアクセスにはDifyアプリのユーザー認証機能があります。
ALBのセキュリティグループ
インバウンドルールは特に編集せず、IP制限を設定していません。とはいえ最も手っ取り早いアクセス制御はALBのセキュリティグループでIP制限することかと考えます。
アウトバウンドルールについて、Cognito認証する場合はポート443番のアウトバウンド通信を許可する必要があります。Amazon Cognitoのトークンエンドポイントへ通信するためです。
所感
非エンジニアでも生成AIワークフローを構築できるDifyをAWSにデプロイすることで、AWSのメリットも享受できるのはDify on AWSの利点かと考えます。
サーバーワークスではDify on AWSのご支援も行っておりますので、ご興味がありましたらぜひ。
