外部で認証されたユーザーへのアクセス (ID フェデレーション)
社内のディレクトリなど、AWS 以外の ID をユーザーがすでに持っているとします。それらのユーザーが AWS リソースを使用する (または、それらのリソースにアクセスするアプリケーションを使用する) 必要がある場合、それらのユーザーには AWS セキュリティ認証情報も必要です。IAM ロールを使用して、ID が組織または第三者のプロバイダー (IdP) からフェデレーションされたユーザーのアクセス許可を指定できます。
注記
セキュリティ上のベストプラクティスとして、IAM ユーザーを作成する代わりに、ID フェデレーションを使用して IAM Identity Center でユーザーアクセスを管理することをお勧めします。IAM ユーザーが必要な特定の状況についての情報は、「IAMユーザー (ロールの代わりに) を作成する場合」を参照してください。
Amazon Cognito を使用したモバイルまたはウェブベースのアプリのユーザーのフェデレーション
AWS リソースにアクセスするモバイルまたはウェブベースのアプリを作成する場合、アプリが AWS にプログラムによるリクエストを送るには認証情報が必要になります。ほとんどのモバイルアプリケーションのシナリオでは、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 ブローカーアプリケーションには、一時的なセキュリティ認証情報を作成するために IAM のトークンサービス (STS) API にアクセスする権限があります。
-
ID ブローカーアプリケーションが、従業員が既存の認証システム内で認証されていることを確認できます。
-
ユーザーは、AWS マネジメントコンソールへのアクセスを与える一時的な URL を入手できます(これはシングルサインオンと呼ばれています)。
一時的なセキュリティ認証情報の作成方法の詳細については、「AWS STS 認証情報を比較する」を参照してください。AWS マネジメントコンソールへのアクセスを取得するフェデレーションユーザーの詳細については、「SAML 2.0 フェデレーティッドユーザーが AWS Management Consoleにアクセス可能にする」を参照してください。