先日書いた、以下の記事の続きです。
前回は、サクッと試すためにアクセスキーで動作確認をしましたが、今回はこれを Azure AD 認証に対応させようと思います。
ローカル開発環境用
ローカル開発環境で試す場合は、以下のドキュメントに従ってアプリ登録をする必要があります。
以下のコマンドを一発叩くだけなのでとても簡単です。
az ad sp create-for-rbac --name <application-name> --role Contributor --scopes /subscriptions/<subscription-id>
このコマンドを実行すると、以下の結果が返ってきます。
{
"appId": "generated-app-ID",
"displayName": "service-principal-name",
"name": "http://service-principal-uri",
"password": "generated-password",
"tenant": "tenant-ID"
}
この情報を以下の環境変数にセットします。これは、本当に環境変数の値が読み込まれるので appsettings.json に記載するなどではダメです。かならず環境変数に設定してください。
| 環境変数名 | 値 |
|---|---|
| AZURE_CLIENT_ID | ↑のappIdの値 |
| AZURE_TENANT_ID | ↑のtenantの値 |
| AZURE_CLIENT_SECRET | ↑のpasswordの値 |
この設定を行った上で CommunicationIdentityClient のコンストラクタの第二引数に DefaultAzureCredential を渡すようにすると AAD 認証が行われて ACS の ID を作ったりアクセストークンの取得が可能になります。DefaultAzureCredential は Azure.Identity という NuGet パッケージが必要になるので、それも追加してください。
第二引数に DefaultAzureCredential を渡すようにしたコードは以下のようになります。コード全体は前の記事を参照してください。
// CommunicationIdentityClient をサービスとして登録しておく
builder.Services.AddSingleton(provider =>
{
var options = provider.GetRequiredService<IOptions<AzureCommunicationServicesOption>>();
return new CommunicationIdentityClient(
new Uri(options.Value.Endpoint),
new DefaultAzureCredential());
});
Azure 用
実際に Azure にデプロイした後はデプロイ先の App Service でマネージド ID を有効化します。
そして、そのマネージド ID に対して Azure Communication Services のリソースの共同作成者を割り当てましょう。
具体的にはユーザーを作りたい Azure Communication Services のリソースを Azure ポータルで開いて「アクセス制御 (IAM)」から、このリソースへのアクセス権の付与にある「ロールの割り当ての追加」から追加します。
この設定をするだけでアプリをデプロイすると自動的に認証がされるようになります。アクセスキーが不要なので安心です。
私の作ったコードをコピペしてデプロイする場合は ACS のエンドポイントへの設定をアプリケーション設定に追加しないといけないので AzureCommunicationServicesOption__Endpoint という名前で ACS のエンドポイントを設定するのを忘れないようにしましょう。
まとめ
Azure AD 認証の方が良いので、基本的にはそれを使いましょう。
Discussion