[AWS] ALBの認証機能でアクセス制限[Google認証]

今回はApplication Load Balancer(以下:ALB)についての記事となります。
ALBとNLBの運用について記事にしましたが、やはりALBは多機能で便利ですね。
今回の記事で試すALBの機能は[認証]というもので、AWS Cognitoで登録したユーザーのみにアクセスを制限したい場合や、Google認証によるログインを求めたい場合に便利な機能となります。

単純なログイン認証やIP制限以外の認証方法が欲しい場合には、アプリケーション側の変更を行うことなくALBの設定だけで実現できてしまうので使い勝手も良さそうですね!

今回の記事ではGoogle認証でのアクセス制限の設定を行います。
Cognitoはこちらの記事へどうぞ。


事前準備


検証用にWebサーバーを用意するのが面倒なので、今回もALBの固定レスポンス機能を使います。
事前準備としてALBを作成して、仮のドメインとSSL証明書をアタッチしておきました。


仮のドメインは[access-test.noname.work]としました。
ブラウザからHTTPS通信でアクセスすると「HelloWorld!!」が表示されることを確認しておきます。

GCP側での準備


Google認証を行うためにGCPでプロジェクトを作成して、GoogleAuthの設定を行います。
認証設定を行う前に[同意画面]の設定を行う必要があります。
画像のように承認済みドメインにトップドメインを登録してください。
ちなみに画像では入力してしまっていますが、アプリケーションホームページのアドレスは必須ではありませんでした。

今回のWebページで使用するドメインは[access-test.noname.work]というサブドメインですが、承認のためのドメインは今回のケースでは[noname.work]というトップドメインを設定する必要があることに注意してください。


続いて認証情報を作成します。
[OAthクライアントID]の作成を押してください。


承認済みのリダイレクトURIは
[https://対象のドメイン/oauth2/idpresponse] を登録します。


認証情報を作成すると[クライアントID][クライアントシークレット]が生成されるため控えておいてください。
このIDとシークレットはいつでもGCPの管理画面から確認が可能です。

ALB側での設定


これで準備が完了したため、ALB側の操作に戻ります。
[リスナールール]から認証の設定を行うことが可能です。


現在の設定ではデフォルトのアクションは固定レスポンスを返すことになっていますが、[アクションの追加]から認証を追加することができます。


認証方法を[OIDC]にして、下記のURLを参考にして必要項目を埋めていきます。
https://accounts.google.com/.well-known/openid-configuration

[発行者]
https://accounts.google.com

[認証エンドポイント]
https://accounts.google.com/o/oauth2/v2/auth

[トークンエンドポイント]
https://oauth2.googleapis.com/token

[ユーザー情報エンドポイント]
https://openidconnect.googleapis.com/v1/userinfo

[クライアントID]
GCPで控えておいたもの

[クライアントのシークレット]
GCPで控えておいたもの


設定保存後にシークレットモードのChromeから検証用のURLである[https://access-test.noname.work]へアクセスしました。するとGoogle認証のためログインページに遷移します。


認証後にWebページが表示されることが確認できました。

ちなみにGoogleアカウントへログインしている状態だと認証ページは表示されません。
また、許可していないドメインのG Suiteへログインしている状態だと、認証ページをスキップしていきなりエラー画面が表示されます。
ただし複数のGoogleアカウント、G-Suiteへログインしている状態だと、認証ページに遷移して、どのアカウントを使うか選択することになります。
これはcookie情報から承認を行おうとするためです。

「あれ?Google認証が出ないぞ?」と思ったならばcookieを削除するか、シークレットモードでアクセスを試みてください。

おわりに

ALBの機能を使うことでアプリケーション側で認証を実装しなくとも簡単にGoogle認証やユーザー認証を実装することができます。

特定の人にしかアクセスして欲しくない社内用のWebツールなどを制限する手段のひとつとして便利かもしれません。
その他にもアプリケーション側の制御やIPアドレスでのアクセス制御など方法はたくさんあると思うので、あくまで選択肢のひとつですが、是非とも活用してみてください。

コメントを残す

メールアドレスが公開されることはありません。 * が付いている欄は必須項目です

日本語が含まれない投稿は無視されますのでご注意ください。(スパム対策)