外部で認証されたユーザー(ID フェデレーション)へのアクセスの許可 - AWS Identity and Access Management

外部で認証されたユーザー(ID フェデレーション)へのアクセスの許可

社内のディレクトリなど、AWS 以外の ID をユーザーがすでに持っているとします。それらのユーザーが AWS リソースを使用する (または、それらのリソースにアクセスするアプリケーションを使用する) 必要がある場合、それらのユーザーには AWS セキュリティ認証情報も必要です。IAM ロールを使用して、ID が組織または第三者のプロバイダー (IdP) からフェデレーションされたユーザーのアクセス許可を指定できます。

注記

セキュリティ上のベストプラクティスとして、IAM ユーザーを作成する代わりに、ID フェデレーションを使用して IAM Identity Center でユーザーアクセスを管理することをお勧めします。IAM ユーザーが必要な特定の状況についての情報は、「IAMユーザー (ロールの代わりに) を作成する場合」を参照してください。

Amazon Cognito を使用したモバイルまたはウェブベースのアプリのユーザーのフェデレーション

AWS リソースにアクセスするモバイルまたはウェブベースのアプリを作成する場合、アプリが AWS にプログラムによるリクエストを送るには認証情報が必要になります。ほとんどのモバイルアプリケーションのシナリオでは、Amazon Cognito の使用をお勧めします。このサービスを AWS Mobile SDK for iOS および AWS Mobile SDK for Android and Fire OS で使用して、ユーザーの一意のIDを作成し、AWS リソースへの安全なアクセスのためにユーザーを認証できます。Amazon Cognito では、次のセクションに示されているのと同じ ID プロバイダーがサポートされます。さらに、開発者が認証した ID と認証されていない (ゲスト) アクセスもサポートされます。また、Amazon Cognito には、ユーザーがデバイスを変えてもデータが保持されるように、ユーザーデータを同期するための API オペレーションも用意されています。詳細については、「モバイルアプリのための Amazon Cognito の使用」を参照してください。

パブリック ID サービスプロバイダーまたは OpenID Connect を使用したユーザーのフェデレーション

可能な限り、モバイルおよびウェブベースのアプリケーションシナリオで Amazon Cognito を使用してください。Amazon Cognito は、パブリック ID プロバイダーサービスを使用する際の裏方作業をほとんど行います。同じサードパーティのサービスで機能し、また匿名サインインもサポートしています。ただし、より高度なシナリオでは、OpenID Connect (OIDC) と互換性がある Login with Amazon、Facebook、Google、その他 IdP でのログインなど、サードパーティのサービスを直接使用できます。これらのサービスを使用した OIDC フェデレーションの使用についての詳細は、「OIDC フェデレーション」を参照してください。

SAML 2.0 を使用したユーザーのフェデレーション

組織が既に SAML 2.0 (Security Assertion Markup Language 2.0) をサポートする ID プロバイダーソフトウェアパッケージを使用している場合、ID プロバイダー (IdP) としての組織と、サービスプロバイダーとしての AWS との間に信頼を作成できます。その後、SAML を使用して、AWS Management Console へのフェデレーティッドシングルサインオン (SSO) または AWS API オペレーションを呼び出すためのフェデレーションアクセスをユーザーに許可できます。たとえば、社内で Microsoft Active Directory と Active Directory Federation Services を使用している場合は、SAML 2.0 を使用してフェデレーションが可能です。SAML 2.0 を使用したユーザーのフェデレーション方法の詳細については、「SAML 2.0 フェデレーション」を参照してください。

カスタム ID ブローカーアプリケーションを作成するユーザーのフェデレーション

ID ストアに SAML 2.0 との互換性がない場合、カスタム ID ブローカーアプリケーションを作成して同じような機能を実行できます。ブローカーアプリケーションはユーザーを認証し、そのユーザー用に一時的な認証情報を AWS に要求して、それをユーザーに提供し AWS リソースにアクセスできるようにします。

たとえば、Example Corp. には、会社の AWS リソースにアクセスする社内アプリケーションを実行する必要のある従業員が多数います。従業員は、会社の ID および認証システムに既に ID があり、従業員ごとに別の IAM ユーザーを作成することは望ましくありません。

Bob は Example Corp の開発者です。Example Corp の社内アプリケーションで会社の AWS リソースにアクセスできるようにするために、カスタム ID ブローカーアプリケーションを開発しています。このアプリケーションは、従業員が Example Corp. の既存の ID および認証システムにサインインしていることを確認します。これには、LDAP や Active Directory などのシステムを使用している可能性があります。ID ブローカーアプリケーションは、従業員の一時的なセキュリティ認証情報を取得します。このシナリオは、前のシナリオ(カスタム認証システムを使用するモバイルアプリ)に似ています。ただし、AWS リソースにアクセスする必要のあるアプリケーションはすべて企業ネットワーク内で実行され、会社には既存の認証システムがあります。

一時的なセキュリティ認証情報を取得するために、ID ブローカーアプリケーションは、ユーザーのポリシーの管理方法と一時的な認証情報の有効期限に応じて、AssumeRole または GetFederationToken を呼び出して、一時的なセキュリティ認証情報を取得します (これらの API オペレーションの違いの詳細については、「IAM の一時的な認証情報」および「一時的なセキュリティ認証情報のアクセス権限を制御する」を参照してください)。この呼び出しは、AWS アクセスキー ID、シークレットアクセスキー、およびセッショントークンで構成される一時的なセキュリティ認証情報を返します。ID ブローカーアプリケーションは、これらの一時的なセキュリティ認証情報を社内アプリケーションで使用できるようにします。アプリは、一時的な認証情報を使用して AWS を直接呼び出すことができます。アプリは、認証情報をキャッシュし、有効期限が切れると、新しい一時的な認証情報をリクエストします。このシナリオを以下に図で示します。


        カスタム ID ブローカーアプリケーションを使用したワークフローの例

このシナリオには次の属性があります。

  • ID ブローカーアプリケーションには、一時的なセキュリティ認証情報を作成するために IAM のトークンサービス (STS) API にアクセスする権限があります。

  • ID ブローカーアプリケーションが、従業員が既存の認証システム内で認証されていることを確認できます。

  • ユーザーは、AWS マネジメントコンソールへのアクセスを与える一時的な URL を入手できます(これはシングルサインオンと呼ばれています)。

一時的なセキュリティ認証情報の作成方法の詳細については、「一時的なセキュリティ認証情報のリクエスト」を参照してください。AWS マネジメントコンソールへのアクセスを取得するフェデレーションユーザーの詳細については、「SAML 2.0 フェデレーティッドユーザーが AWS Management Consoleにアクセス可能にする」を参照してください。