#参考記事
目的
VPNに依存しないセキュアな構成を求められる案件が増えていますが、ALBで強力な認証を持っている、AzureAD(O365の認証基盤)、Googel(google workspaceの認証基盤)を用いることにより簡易にセキュアなアプリケーションアクセスが提供できると考えています。
しかしながら、実案件ですと、子会社は別のo365テナントといった話があり、1つの認証プロバイダーで済まない案件も存在します。
ということで、本記事では、複数認証プロバイダー（AzureAD*2）＋albで認証する構成を組んでみます。
概要
ALBのリスナーのルール設定で、クエリに応じたOIDCを設定するといった内容になります。
手順
- 1つめのOIDC設定
- Azure AD1にアプリケーションを登録する
- ALBに設定する
- 動作確認
- 2つめのOIDC設定
- Azure AD2にアプリケーションを登録する
- ALBにルールを設定する
- ALBに設定する
- 動作確認
の流れを説明します。
（アプリケーションの配置、ALBの設定は省略します）
1つめのOIDC設定
Azure AD1にアプリケーションを登録する
Azureにログインして、Azure Active Directory -> アプリの登録からアプリケーションを登録します
Redirect URIは以下を指定します。
https://Route53に登録したALBのエイリアスレコード/oauth2/idpresponse
次に、概要、および、エンドポイントを開き、ALBに登録するための情報を表示します。
また、証明書とシークレットより、シークレットを作成します。
ALBに設定する
次にALBに前述の情報を登録していきます。
ALBのリスナー、ルールを開き、
認証の追加を選択します。
次に、認証方法で、OIDCを開くと下記画面になります。
で、前述のazureADの情報でこれを埋めていかなければならないのですが、
置換が必要な値あり、各ページに値が散っている、固定値ありと表で理解しようとすると煩雑です。
|ALBの設定値 | 対応するAzure側の値|
|:-----------|------------:|:------------:|
|認証 「OIDC」選択| NA|
|発行者| エンドポイント:「OAuth 2.0 承認エンドポイント (v2)」の"/oauth2/v2.0/authorize"の部分を"/v2.0"で置換したURL|
|認証エンドポイント | エンドポイント:OAuth 2.0 承認エンドポイント (v2)|
|Tトークンエンドポイント| エンドポイント:OAuth 2.0 トークン エンドポイント (v2)|
|User info endpoint | https://graph.microsoft.com/oidc/userinfo|
|クライアント ID | 概要:アプリケーション (クライアント) |
|クライアントのシークレット| 証明書とシークレット:作成したシークレット|
ということで、マッピング図を示します。
では、入力でき、saveしたらテストをしましょう。
動作確認
URLにアクセスすると、このようなダイアログが表示され、ALB＋azureADで認証されてることがわかります。
（なお、auzreADにログイン済み（o365使用中）のため、上記のダイアログが出ています。azureADにログインしていない場合は、auzreADのログイン画面が表示されます。）
2つめのOIDC設定
それでは、２つ目のアプリケーションを登録していきましょう。
###Azure AD2にアプリケーションを登録する
といっても、ここは一つ目と同じなので割愛します。
ALBにルールを設定する
リスナーでルールの追加を選択し、クエリに「oauth=azuread2」と入っている場合、2つ目のazureADを使うように構成します。
（実際のクエリ指定時には、バッティングの恐れがない、もっと複雑なキーが良いと思います）
先程と同じ要領で、設定を追加します。
認証の設定が終わったら、同じ転送先を選択します。
クエリを付けてURLを呼び出すと、先ほどとは異なるazureADで認証されてることが確認できます。
