CognitoとALBの連携検証 - nozakitakahirokunのブログ

目的・やりたいこと

Cognito検証環境でALB＋Cognito構築し、ALB配下のEC2で作成したWebサイトを見に行くときに、Cognito認証＋MFA認証ができるようにする

対象者

WebサイトにCognito認証を掛けてセキュリティを向上させたいケース

対象となる技術

Cognito
ALB
MFA

条件（導入にあたって前提事項）

Webサイトは構築済み
HTTPSページもオレオレ証明書を使って構築済み（Cognitoのユーザー認証はHTTPSリスナーでのみサポートされているため、HTTPS化は必須）
ドメイン取得済み（CognitoドメインやACM証明書を作成するときに使います）
セキュリティグループは事前に適切に開放されているものを付与しているものとします。

参考URL

注意事項

ドメイン取得時に若干ハマったことがあったのでご紹介しておきます。

ドメインはお名前.comで取得しました。1年間無料で更新費用さえ払わなければ更新するまで無料で使えます。
nozaki.comはさすがに取得済みであったため、nozaki2.comを取得しました。
ところが、ACM証明書のリクエストでステータスがいつまでも「保留中の検証」のまま・・

どうやらACM指定のDNS検証のためのCNAMEレコードがちゃんと登録されていないようで、試しにa.nozaki2.comで値をbにしたCNAMEレコードを登録してみても、問い合わせに返答がない。

$ dig a.nozaki2.com CNAME

; <<>> DiG 9.10.6 <<>> a.nozaki2.com CNAME
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 40113
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4000
;; QUESTION SECTION:
;a.nozaki2.com.         IN  CNAME

それもそのはず。お名前.comで取得したドメインのレコードをRoute 53で登録しようと思ったら、お名前.com側でネームサーバーの変更を行い、Route 53のNSレコードを指定する必要があった。

この設定変更後、しばらくすると無事CNAMEが引けるようになった。

$ dig a.nozaki2.com CNAME

; <<>> DiG 9.10.6 <<>> a.nozaki2.com CNAME
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 32984
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4000
;; QUESTION SECTION:
;a.nozaki2.com.         IN  CNAME

;; ANSWER SECTION:
a.nozaki2.com.      300 IN  CNAME   b.

証明書も無事「発行済み」に

Cognito設定後、永遠とredirect_mismatchエラーに見舞われることに

このサイトが参考になりました。どうやらコールバックURLが適切でないとこれが出る模様

「redirect_mismatch」エラーは、認証リクエストの redirect_uri パラメータが、Amazon Cognito でアプリに設定されたリダイレクト URI と一致しない場合に発生します。これは、ユーザーをブラウザから Android アプリにリダイレクトしようとしているときに発生する可能性があります。
Amazon Cognito でアプリを設定するときは、そのアプリのリダイレクト URI を指定する必要があります。リダイレクト URI は、ユーザーがサインインした後にリダイレクトされる URL です。認証リクエストのリダイレクト URI がアプリに設定されたリダイレクト URI と一致しない場合、Amazon Cognito は「redirect_mismatch」エラーを返します。

自分の場合はそれだけでは直らなかったため、アプリケーションクライアントの[ホストされた UI]を編集しました。

[OAuth 2.0 許可タイプ]で、「暗黙的な付与」も許可したら直りました。

作業の流れ

概要図

事前作業

1．ターゲットグループの作成
HTTPS化。ヘルスチェックもHTTPSで

2．ALBの作成
ネットワークマッピングでサブネットの指定がポイント。最初誤ってターゲットが存在するプライベートサブネットを指定してしまった。そうすると「インターネットゲートウェイへのルートがありません。」と警告が出るはず。インターネットfacingのALBの場合はそうするとインターネットから繋がらなくなってしまう。
なのでここはIGWが存在するパブリックサブネットを指定（もう一つのダミーのパブリックサブネットはIGWを置いていないので、このように警告出てます）

3．リスナーの指定
ALB⇨EC2でHTTPS化されたWebサイトを見に行けるようにしておく必要があるため、リスナーの作成がポイントになる。
プロトコルはHTTPS化。そうするとセキュリティポリシー（デフォルトでOK）やACM証明書を指定する欄が現れる。

ACM証明書はこの場で作成してもOK。ここでは「注意事項」で苦労して作成したACMを指定

4．ALBのDNS名をRoute 53に追加
HTTPSアクセス自体はこれなしでもできますが、おそらく証明書の警告や覚えやすいドメインでアクセスしたい場合は必要な作業。ALBのDNS名は長くて覚えられないので
これにはAレコードのエイリアスレコードを使います。レコードの作成でAレコードのまま、「エイリアス」を有効化します。すると［トラフィックのルーティング先］という欄が現れるので、ALBやリージョン、dualstack〜と名付けられたALB名をそれぞれ選択します。