![[新機能] Application Load Balancer(ALB)に新たに追加された認証機能を使う（独自IdP編）](https://devio2023-media.developers.io/wp-content/uploads/2015/02/elb.png)
[新機能] Application Load Balancer(ALB)に新たに追加された認証機能を使う（独自IdP編）
こんにちは。こむろです
唐突にALBの組み込み認証機能が追加されました。この認証機能を使うことでアプリケーションに認証機能を実装することなく、手前のLoad Balancerで認証の制御が可能になるということで、とてもインパクトのあるアップデートかと思います。
OIDCに準拠（IdProvider）の弊社の認証サービスが手元にあったので、今回は独自IdProviderを使い、ALBで認証機能を利用できるようにしてみました。
超簡単。レッツ3分（？）クッキング。
必要なもの
- Application Load Balancer
- prismatix 認証サービス(OIDC準拠の認証基盤：IdProvider)
- VPC(複数のSubnetを持ち、Internet Gatewayがアタッチ済み)
作業手順
ALBを作成していきます。今回はポート443をListenerとして設定し、HTTPSでリクエストを受けるようにします。完成構成図として雑な構成図を書きました。完成図はこんな感じです。
本来、ALBの裏側のインスタンスの中で可動するアプリケーションが、認証を呼び出す機能などを実装する必要があるのですが入り口のALBが認証機能の呼び出しを行ってくれるようなので、とても楽になります。ALBを通ってきたリクエストはすでに認証済みのものとなるためです。
ALBを用意します
Application Load Balancerを選択します。
ListenerはHTTPSを選択します。作成済みのVPCを選択し、2個以上のAvailability Zoneを設定します。
HTTPSで通信するために証明書を紐づけます。ACMで管理された証明書を選択します。今回は、以前サンプルで作成した証明書を流用しました。
Security Groupを設定、作成します。Load balancerへ接続するための適切なSecurity Groupを設定しておきます。
サンプルアプリケーションが稼働しているインスタンスをターゲットに参加させます。
作成したLoad balancerがActiveになるまで待ちます。
Ruleを編集
ここからが本番です。Ruleを編集して認証機能を追加していきましょう。作成したLoad Balancerを選択し、Listenerタブを開きます。
View/Edit Rule をクリックします。
Ruleの編集画面です。 IF~THEN とブロックの構造になっておりとてもわかり易いのではないでしょうか。
上部タブの + タブを押すとRuleの追加画面になります。ここで Insert Rule を押すとRuleの追加編集画面が出てきます。
認証機能を追加する
Add Condition をクリックすると2つの選択肢が出てきます。 Host is..., Path is... 今回は、すべてのPathに対して認証機能を有効にしたいので、 Path is... を選択し /* を入力します。青い丸チェックを押すと、設定が適用されます。
条件が決まったので次は、Actionを定義します。 Add Action をクリックすると、 Forward to..., Authenticate... が出てくるのがわかります。認証機能を挟むために Authenticate... を選択します。
Authenticateは Cognito と OIDC が選択できるようです。prismatix 認証サービスはOIDC準拠（IdProvider）の認証基盤なのでOIDCを選択します。
多くの設定項目が出てきました。こちらを埋めていきます。
| 項目名 | 説明 |
|---|---|
| issuer | JWTの発行者。 https:// から始まるURL |
| Authorization Endpoint | ユーザーの認証及び認可委譲の承諾を得るためのエンドポイント |
| Token Endpoint | アクセストークンを発行するためのエンドポイント |
| Userinfo Endpoint | リソースオーナーのOIDCユーザー情報表現を取得ためのエンドポイント |
| Client Id | Relying PartyのID |
| Client Secret | Relying PartyのSecretKey |
prismatix 認証サービスはすでに公開されたアプリケーションが稼働しているのでそちらを利用します。
追加でRequest Headerをカスタムすることができるようです。
また未認証（Unauthorized）ユーザーに対しての動作も変更できるようです。
同じく丸チェックをクリックして適用します。
Forwardを設定
最後に認証通過後のForward先のTarget Groupを設定します。こちらを設定しないと認証後に迷子になってしまうので、必ず設定します（というか設定しないと、Saveができません）
Add Action で Forward to... を選択し、Forward先のTarget Groupを指定します。
こちらも忘れなく青丸チェックで適用します。すべての設定が終わると Save がクリックできるようになります。Saveを押してRuleを保存します。
Ruleが作成されました。
prismatix 認証サービスのログイン画面が表示
ALBへブラウザでアクセスしてみます。通常であればTarget Group以下のインスタンスで稼働しているアプリケーションのコンテンツが見えるはずですが、未認証なので
prismatix 認証サービスのログイン画面へ遷移しました。登録済みのユーザー名とパスワードを入力すると、Target Groupで設定した画面へ遷移します。
おまけ
編集するたびにSecretの入力を要求される
パスの設定を修正しようとしたところ、エラーが出ました。
編集しようとすると 必ず Secretの値の再入力を要求されます。気をつけましょう。
Scopeを間違えるとHTTP Status 561???
OIDCの設定でScopeはデフォルトでは openid が指定されています。今回は root を指定すべきだったのですが、こちらの設定はAdvancedにあるためすっかり忘れていました。その結果。
見たことがないHTTP Statusが返却されました。エラー内容についてはURLの中に記載されてたのを見つけました。
ちょっと分かりづらいかもしれません。
まとめ
ちょうどOIDCの認証するクライアントの機能を実装しようとしていたところ、突然発表があったため急遽実際に使えるかを調べてみました。その結果、チーム内で内容がほぼかぶるという失態（しかも自分のほうが後発）を犯しましたが、ALBの強力なアップデートを知ることができたので結果オーライです。
認証のための機能を一つ、実装から削ることができるためとても助かりそうです。実際に自分が担当しているサービスに組み込んで利用してみたいと思います。
