Application Load Balancer 組み込み認証によりログインを簡略化

本日は、Application Load Balancer (ALB) に組み込みの認証サポートを発表できることにワクワクしています。ALB は、今後、ユーザーがアプリケーションにアクセスする際、ユーザーを安全に認証できるようになり、開発者に認証をサポートするためコードを書く必要を排除し、バックエンドからの認証責任を軽減させます。チームは認証機能を試せる素晴らしいライブサンプルの環境を構築できます。

アイデンティティベースのセキュリティは、最新のアプリケーションの重要なコンポーネントであり、顧客がミッションクリティカルなアプリケーションのクラウドへの移行を継続するにつれて、開発者は同じ認証コードを何度も何度も実装するように要求されます。企業は、それぞれのクラウドアプリケーションによりそれぞれのオンプレミスアイデンティティを使用したいと考えています。ウェブ開発者は、ソーシャルネットワークのフェデレーシフェデレーティッド認証を使用して、それぞれのユーザーがサインインできるようにしたいと考えています。ALB の新しい認証アクションは、Google、Facebook、および Amazon Cognito を通した Amazon のようなソーシャルアイデンティティプロバイダ (IdP) を通した認証を提供します。さらに、任意の OpenID Connect プロトコル準拠の IdP とネイティブで統合され、セキュアな認証およびご使用のアプリケーション間でのシングルサインオンを提供します。

ALB 認証が機能する方法とは？

認証は複雑な話題であり、読者の皆さんの専門知識のレベルが同じとは限りません。それゆえ、皆さんのすべてに適用可能な状況が確実であるようないくつかの重要な概念をカバーしたいと思います。あなたがすでに認証の専門家であり、ALB 認証がどのように機能するかだけを確認したい場合には、次のセクションをご自由に飛ばしてもらっても構いません！

• 認証とは、アイデンティティを検証することです。
• 許可とは、1 個のアイデンティティが実行を許可される「モノ」へのアクセス許可です。
• OpenID Connect (OIDC) は、シンプルなアイデンティティまたは認証のレイヤーであり、OAuth 2.0 プロトコルの最上位階層に構築されるレイヤーです。OIDC 仕様書はかなりよく書かれており、機会があれば読んでみるべき価値があるものです。
• アイデンティティプロバイダー (IdP) はアイデンティティ情報を管理し、認証サービスを提供します。ALB は任意の OIDC 準拠 IdP をサポートしており、Amazon Cognito や Auth0 を使用し、Active Directory、LDAP、Google、Facebook Amazon のようなさまざまな IdP からか、または AWS もしくはオンプレミスでデプロイされたその他のタイプからかの、異なるアイデンティティを集約することができます。

専門用語からは少し離れてしまいますが、これらのすべての事項は、ユーザーが誰であるか、彼らには何を実行することが許可されるのかと言うことに帰結します。これをセキュアでかつ効率的に実行することは困難です。従来、企業では、それぞれの IdP に SAML と呼ばれるプロトコルをしていて、それぞれの社内ユーザー向けにシングルサインオン (SSO) エクスペリエンスを提供していました。SAML は XML 依存性が高く、クレームを共有するために JSON 書式による OIDC を使用し始めた最新のアプリケーションです。開発者は Amazon Cognito の SAML サポートによる ALB で SAML を使用することができます。ウェブアプリやモバイルアプリの開発者は、通常、使い勝手がよい、Amazon Cognito でもサポートされる、Facebook、Amazon、Google などのソーシャル IdP を経由するフェデレーティッドアイデンティティを使用しますが、

ALB 認証は、1 つのリスナールール で 1 回の認証アクションを定義することにより機能します。ALB の認証アクションは、着信リクエストに 1 個のセッションクッキーが存在することをチェックしてから、それが有効であることをチェックするようになります。セッションクッキーが設定され、有効にされてから、ALB はリクエストを X-AMZN-OIDC-* ヘッダーセットが付加された、ターゲットグループにルーティングすることになります。これらのヘッダーには、バックエンドが個別のユーザーを識別するために使用できる、JSON ウェブトークン (JWT) 形式の アイデンティティ情報が含まれています。そのセッションクッキーが設定されていないか、または無効な場合には、それから、ALB は OIDC プロトコルに従い、アイデンティティプロバイダーに HTTP 302 リダイレクトを発行することになります。このプロトコルは、解凍項目がたくさんあり、これらの興味深い機能に関してそのドキュメントは完全に網羅しています。

ALB 認証のウォークスルー

いくつかの AWS Fargate コンテナ内で実行中の 1 個の Amazon ECS クラスター内にシンプルな Python フラッシュアプリがあります。これらのコンテナは、1 個の ALB によりルーティングされる 1 個のターゲットグループ内にあります。対称アプリケーションの認証された部分に対象アプリケーションのユーザーたちがアクセスする前に、彼らがログインしていることを確実にしたいのです。最初に、対象コンソール内で ALB にナビゲートし、それらのルールを編集することになります。

すべてのアクセスが、 /account* を対象することを確実にしますエンドポイントが認証されるので、個別のエンドポイントに対して一致する 1 個の条件を持つ新しいルールを追加してみましょう。

ここで、1 個の新しいルールを追加し、そのルール内に 1 件の認証アクションを追加してみることにします。

いくつかの設定詳細項目を提供することにより、ALB に 1 個の新規 Amazon Cognito ユーザープールを作成させてみましょう。

Amazon Cognito プールを作成した後、詳細設定でいくつかの追加設定を行うことができます。

デフォルトクッキー名を変更したり、タイムアウトを調整したり、スコープを調整したり、未認証のリクエストに関するアクションを選択したりできます。

すべての未認証リクエストに関して 1 件の 401 を発行するために DENY を選択するようになるか、または未認証の場合に、対象アプリケーションにパススルーすることになる Allow を選択するようにします。これは、シングルページアプリケーション (SPA) 向けに役立ちます。これで、対象ユーザーを認証し、その既存のページを再読み込みするために、この Amazon Cognito のケースでは、その IdP のダイアログを表示させることになる Authenticate を選択することになります。

ここで、対象ターゲットグループ用に 1 回の転送アクションを追加し、そのルールを保存してみましょう。

Facebook 側では、Amazon Cognito User Pool Domain をホワイトリストに登録された Oauth リダイレクト URL (複数) に追加するだけです。

その他の認証プロバイダーに関しても同様のステップを実行することになります。

ここで、認証済みページにナビゲートする場合、対象 Fargate コンテナが、ALB により X-Amzn-Oidc-* ヘッダーセットを付加された発信元リクエストを受信します。これらのヘッダー (クレーム – データ、アイデンティティ、アクセス – トークン) の情報を使用して、対象アプリケーションが認証を実装することができます。

これらのすべては、それぞれの IdP を処理するためのコードを 1 行も書く必要もなしに可能にされました。しかしながら、対象リクエストが改ざんされていないことを担保する JWT ヘッダー上の署名を検証するためのアプリケーションを実装することは依然として重要です。

その他のリソース

もちろん、本日確認したすべての項目は、また、API および AWS コマンドラインインターフェイス (CLI) にてもご利用可能です。本機能の追加情報については、「ドキュメンテーション」にて参照することができます。

同様にライブサンプルもチェックすることを確実にしてください。

ALB に組み込まれた認証により、開発者は ALB のスケーラビリティ、可用性、および信頼性を常時維持すると同時に、すべてのアプリケーションの認証を再構築するのではなく、それぞれのアプリケーションの構築に集中することができます。この機能は非常に重要な意味を持つ機能であると考えられるため、顧客の皆様がそれにより構築するものを見ることにとても興味がわきます。皆さんがこの機能について思うところをコメントやツイッターで教えてください！

– Randall