何に使う？
サイトの正式公開前に関係者だけで評価したいなどのユースケース
制限等
- App Service なら X-Azure-FDID でロックダウンし、
*.azurewebsite.netへの直接アクセスを防ぐことは出来る
- しかし、Blob Storage による Static website などの場合は上記は使えないので
*.web.core.windows.netへのアクセスは防げない(現状の無印 Front Door で何か良い方法があったら教えてください)。これは2021/12現在はまだプレビューだが Private Link を使えば保護できるっぽい(まだ私は試してない)。
- 残念ながら Front Door だけでは構成することができず、401 Authorization Requiredを返すことのできる Webサイトが必要。理由は後述。
構成
「ルール エンジンの構成」を使い、リクエストヘッダーに
Authorization: Basic xxxxx
が存在しない場合、
HTTP/1.1 401 Authorization Required
WWW-Authenticate: Basic realm="hogehoge"
を返すサイト(バックエンドプール)に転送する。
「ルール エンジンの構成」では要求ヘッダー、応答ヘッダーを書き換えることは出来きるので、応答ヘッダーとしてWWW-Authenticateを返す事はできるが、残念ながらレスポンスコードの操作はできないので何らかの401応答サイトが必要。
401応答サイトに関して
これは特に Azure である必要もないし、実際にサービスを行うサイト(App Service等)の特定パスに Basic認証をかける様にしてバックエンドプールとして定義しても良いと思う。自分はテスト的に行ったので、既存の外部サイトを用いた。App ServiceやDocker上の各種Webサーバーでの方法は検索すればすぐに見つかると思うのでここでは触れない。
設定
Front Door デザイナー
詳細は省くが、バックエンドプールとして hoge と basicAuth を用意した。/*へのアクセスが hogeバックエンドに回る設定。basicAuthは既存で運用しているBasic認証ありの外部サイトを指定した。
ルール エンジンの構成
すでに説明した通り、Authorization要求ヘッダーがBasic xxxxと等しくない場合は、ルーティングの構成をbasicAuthバックエンドプールに回すようにしてるので401とWWW-Authenticateが返される。結果としてブラウザー側にばBasic認証のダイアログが表示され、次のリクエストからはAuthorizationヘッダーが付与されたリクエストが送られてくる。
なお画面キャプチャのサンプルの値は username=user, password=pass の値になる。念の為導出方法を。
$ echo -n user:pass | base64
dXNlcjpwYXNz
SPAの場合(おまけ)
よくある、Frontend SPA + Backend APIの様な構成で、外部で認証してJWTを取得し、APIを呼び出す(Authorization: Bearer)構成の場合は、Frontend側だけにルールエンジンとの関連付けを行い、API側はには関連付けは行わないこと。と言っても前述の通り Blob Storage Static website の場合、直接アクセスをどう防ぐか問題が出てくるんですが…。（ご存知の方教えてください）