AWS Single Sign-On の次の進化



大規模なユーザー ID を効率的に管理するには、多くの組織が現在使用している複数の ID ソースをつなぐ新しいソリューションが必要です。お客様は、自社のアプリ、サードパーティのアプリ (SaaS)、および AWS クラウド環境全体で単一の ID およびアクセス戦略を確立したいと望んでいます。

本日、AWS Single Sign-Onの次の進化を発表いたします。これにより、Azure AD を使用している企業は、AWS Single Sign-On によって既存の ID ストアを活用できるようになります。さらに、Azure AD からのユーザー ID とグループの自動同期もサポートされています。これで、既存の Azure AD ID を使用して AWS 環境を構成する複数のアカウントとアプリケーションにサインインできるようになりました。追加のユーザー名とパスワードを覚える必要はなく、使い慣れたサインインの方法を使用できます。加えて、管理者は、すべての AWS アカウントとアプリへのアクセスを一元的に設定する便利さを確保しながら、Azure AD のユーザー ID の信頼できる唯一のソースの管理に集中することもできます。

既にユーザー ID に Azure AD を使用している企業の管理者であり、既存の ID を使用するユーザーに対して AWS 環境のシンプルで簡単な使用を可能にしたいと考えていると想像してみてください。AWS Single Sign-On で Azure AD のグループとユーザーメンバーシップの設定を手動で複製し、2 つの ID システムを維持することは避けたいので、自動同期を有効にします。ユーザーは、Azure AD で既に慣れているやり方で AWS 環境にサインインします。Azure AD でアプリケーションへのシングルサインオンを有効にする方法の詳細については、こちらをご覧ください。AWS アカウントとアプリケーションへのアクセス許可の管理の詳細については、AWS Single Sign-On ユーザーガイドを参照してください。

AWS Single Sign-On の ID ソースとしての Azure AD の接続
最初のステップは、Azure AD と AWS Single Sign-On を接続することです。まず、アカウントの Azure Portal にサインインし、Azure Active Directory ダッシュボードに移動します。左側のナビゲーションパネルで [Enterprise Applications] を選択します。

次に、[+ New application] をクリックし、[Non-gallery application] を選択します。表示される [Add your own application] ページで、[Name] フィールドに AWS SSO と入力 (好きな名前を使用できます) し、[Add] をクリックします。数秒後、新しいアプリケーションが作成され、アプリケーションの設定概要にリダイレクトされます。

ここで、シングルサインオンを有効にし、Azure AD と AWS Single Sign-On の間でフェデレーションメタデータを交換するための設定を行います。ナビゲーションパネルで [Single sign-on] を選択し、[SAML] オプションをクリックします。次に表示される設定ページで、フェデレーションメタデータ XML ファイルをダウンロードする必要があります。このファイルは、[SAML Signing Certificate] パネルに表示されます。デフォルトで AWS SSO.xml という名前のこのファイルは、次の手順で AWS Single Sign-On を設定するために使用されます。

ファイルをダウンロードしたら、別のブラウザータブを開き (後で戻る必要があるため、[Azure AD] タブは開いたままにします)、AWS Single Sign-On コンソールにサインインします。ダッシュボードのホームで、[Enable AWS SSO] ボタンをクリックします。数秒後、アカウントでシングルサインオンが有効になり、Azure AD との接続の設定に進むことができます。

ナビゲーションパネルの [Settings] をクリックして、[Change] リンクをクリックし、オプションのリストから [External identity provider] を選択して、ID ソースを最初に設定します。ここで、やるべきことが 2 つあります。最初に、ページ上のリンクを使用して AWS SSO SAML メタデータファイルをダウンロードする必要があります。これを Azure AD ポータルに戻す必要があります。次に、ID プロバイダーメタデータセクションで Azure AD からダウンロードした XML ファイルを参照して選択します。

[Next: Review] をクリックして、提示されたフィールドに CONFIRM と入力し、最後に [Change identity source] をクリックしてプロセスの AWS Single Sign-On 側を完了します。

Azure AD の [Set up Single Sign-On with SAML] 設定ページを開いたままのタブに戻り、ページの上部にある [Upload metadata file] ボタンをクリックします。AWS Single Sign-On 設定の [AWS SSO SAML metadata] リンクからダウンロードしたファイルに移動して選択し、表示される [Basic SAML Configuration] フライアウトで [Save] をクリックします。この時点で、Azure AD のユーザーと一致するユーザー名である AWS Single Sign-On のユーザーアカウントを既に持っている場合、[Test] ボタンをクリックして設定を確認することができます。

ユーザー数が比較的少ないお客様は、自動プロビジョニングに頼るのではなく、AWS Single Sign-On でユーザーアカウントを管理し続けることをお勧めします。サインインの側面のみを使用することができるので、ここで停止することができます。ただし、便利なので、自動プロビジョニングを有効にすることをお勧めします。Azure AD グループに追加する新しいユーザーは、追加のアクションを必要とせずに自動的にアクセスできるため、管理が容易になり、エンドユーザーの生産性が向上します。Azure AD のグループから削除されたユーザーは、AWS Single Sign-On の関連するアクセス許可に自動的にアクセスできなくなるというセキュリティ上の利点もあります。

自動プロビジョニングを有効にする
ユーザーが AWS Single Sign-On を使用して接続するように、Azure AD をシングルサインオン用に設定したので、次はユーザーアカウントの自動プロビジョニングを有効にします。新しいアカウントが Azure AD に追加され、作成した AWS SSO アプリケーションに割り当てられ、それらのユーザーが AWS にサインインすると、対応する AWS Single Sign-On ユーザーが自動的に作成されます。管理者として、AWS で対応するアカウントを設定して Azure AD ユーザーにマッピングする作業を行う必要はありません。

AWS Single Sign-On コンソール から [Settings] に移動し、[Enable identity synchronization] リンクをクリックします。これにより、SCIM エンドポイントと OAuth ベアラーアクセストークン (デフォルトでは非表示) の値を含むダイアログが開きます。Azure AD アプリケーションの設定でこれらの値の両方を使用する必要があるため、両方の値をメモするか、複数のブラウザータブを使用して、コピー/貼り付けを行います。

Azure AD ブラウザータブおよび AWS SSO アプリケーションに戻って、ナビゲーションパネルで [Provisioning] をクリックし、[Provisioning Mode]を Automatic に設定します。これにより、AWS Single Sign-On コンソールのダイアログから値を入力する必要があるフィールドの表示がトリガーされます。最初に、SCIM エンドポイントの値を [Tenant URL] フィールドに貼り付けます。次に、アクセストークンを [Secret Token] フィールドに貼り付けます。

Notification Email の値を入力して設定を完了し、プロビジョニングエラーが発生したときに E メールを受信するようにオプトインし、[Test Connection] ボタンをクリックして、すべてが期待どおりに機能することを確認します。すべてが正常であるなら、ページツールバーの [Save] をクリックし、属性のマッピングを設定するための簡単な手順をいくつか実行するだけで完了です。

[Mappings] を展開して、[Synchronize Azure Active Directory Users to customappsso] リンクをクリックします (リンクは「…to AWS SSO」と表示される場合があります)。これにより、属性マッピングを管理するページに移動します。そのセクションでは、facsimileTelephoneNumber および mobile 属性を使用しないため削除し、mailNickname 属性をクリックして編集し、Source 属性を objectId に変更します。[Save] をクリックして [Settings] 画面に戻ります。もう 1 つ手順が残っています。同期を有効にするには、[Provisioning Status ] で [On] をクリックし、もう一度 [Save] をクリックします。

最初の同期は、約 40 分ごとに発生する後続の同期よりも時間がかかることに注意してください。進行状況を確認するには、Azure AD で同期の詳細または監査ログを表示するか、AWS Single Sign-On コンソールのナビゲーションパネルで [Users] を選択します。

シングルサインオンを設定しました、次は?
これで、Azure AD がユーザー ID とグループへの割り当ての信頼できる唯一のソースとなり、定期的な同期により AWS Single Sign-On で対応するユーザー ID が自動的に作成されます。ユーザーは Azure AD の認証情報と経験を使用して AWS のアカウントとアプリケーションにサインインできるようになり、追加のユーザー名とパスワードを覚える必要はありません。ただし、現状では、ユーザーにはサインインするためのアクセス権しかありません。AWS にサインインした後にアクセスできるものに関してアクセス許可を管理するには、AWS Single Sign-On コンソールを使用して AWS Single Sign-On でアクセス許可を設定する必要があります。AWS Single Sign-On は、割り当てにアクセス許可セットの概念を使用します。アクセス許可セットは、本質的に AWS Identity and Access Management (IAM) ポリシーをアタッチする標準のロール定義です。許可セットを定義すると、指定したアカウントのアクセス許可セットにグループまたはユーザーを割り当てます。そうすると、AWS Single Sign-On は、指定されたアカウントに、そのグループまたはユーザーへのアクセスを付与するすべての権利情報を含め、基盤となる AWS Identity and Access Management (IAM) ロールを作成します。アクセス許可セットの詳細については、AWS Single Sign-On ユーザーガイドをご覧ください。

下のスクリーンショットでは、自動同期の効果を確認できます。Azure AD で、3 つのグループを作成し、2 つのグループにユーザーアカウントを割り当てました (このブログ記事のため)。同期が完了して AWS Single Sign-On コンソールに切り替えると、3 つのグループが自動的に作成され、選択したグループにユーザーアカウントが割り当てられていることがわかります。

ナビゲーションパネルの [AWS Accounts] と [Applications] のリンクから利用できるアクセス許可セットを使用して、1 つ以上のアクセスコントロールポリシー (作成したカスタムポリシー、または AWS Identity and Access Management (IAM) マネージドポリシー) をグループとユーザーの両方に関連付け、ユーザーがサインインした後のアクセス許可をコントロールできます。サインインは使い慣れた Azure AD でのやり方を使用して行われ、ユーザーは引き受けるアカウントとロールを選択できます。また、サインインは、AWS コンソールや CLI を使用して行うこともできます。AWS コマンドラインインターフェイス (CLI) のバージョン 2 でシングルサインオンを使用する方法の詳細は、このブログ記事で詳しく説明しています。

この記事では、新しい AWS Single Sign-On 機能を活用して、シングルサインオンのために Azure AD ユーザー ID を AWS アカウントとアプリケーションに一元的にリンクする方法と、ID を管理および使用する際の複雑さを軽減するために、新しい自動プロビジョニングサポートを使用する方法を示しました。管理者はユーザーの管理で信頼できる唯一のソースを使用できるようになり、ユーザーは AWS アカウントとアプリケーションにサインインするために追加の ID とパスワードを管理する必要がなくなりました。

この次の進化は、AWS Single Sign-On がサポートされているすべてのリージョンのすべてのユーザーが利用できるようになりました。AWS Single Sign-On のリージョンごとの可用性は、こちらで確認できます。

— Steve