エンドユーザークライアントアプリケーションの認証 - Amazon Chime SDK

翻訳は機械翻訳により提供されています。提供された翻訳内容と英語版の間で齟齬、不一致または矛盾がある場合、英語版が優先します。

エンドユーザークライアントアプリケーションの認証

エンドユーザークライアントアプリケーションから Amazon Chime SDK メッセージングを実行することもできます。 バックエンドサービスから SDK 呼び出しを行うでは、create-channel、 send-channel-message、 などの API コールを行う方法について説明します list-channel-messages。ブラウザおよびモバイルアプリケーションなどのエンドユーザークライアントアプリケーションがこれらの同じ API コールを行います。クライアントアプリケーションは、 経由で接続 WebSocket して、メンバーであるチャネルへのメッセージやイベントのリアルタイムの更新を受信することもできます。このセクションでは、特定のアプリケーションインスタンスユーザーを対象とするクライアントアプリケーションに IAM 認証情報を付与する方法について説明します。エンドユーザーがこれらの認証情報を取得すると、バックエンドサービスから SDK 呼び出しを行う に示す API コールを行うことができます。クライアントアプリケーションの完全なデモを見るには、https://github.com/aws-samples/amazon-chime-sdk/tree/main/apps/chat を参照してください。クライアントアプリケーションが属するチャネルからリアルタイムメッセージを受信する方法について詳しくは、「 WebSockets を使用したメッセージの受信」を参照してください。

エンドユーザーへの IAM 認証情報の付与

Amazon Chime SDK メッセージングは、 AWS Identity and Access Management (IAM) ポリシーとネイティブに統合され、受信リクエストを認証します。IAM ポリシーは、個々のユーザーができることを定義します。IAM ポリシーは、ユースケースに合わせてスコープダウンされ限定された認証情報を提供するように作成できます。Amazon Chime SDK メッセージングユーザーに対するポリシー作成の詳細については、「IAM ロールの例」を参照してください。

既存のアイデンティティプロバイダーをお持ちの場合、既存のアイデンティティを Amazon Chime SDK メッセージングと統合するための以下のオプションがあります。

  • 既存の ID プロバイダーを使用してユーザーを認証し、認証サービスを AWS Security Token Service (STS) と統合して、クライアント用の独自の認証情報供給サービスを作成できます。STS には IAM ロールを引き受けるための API が用意されています。

  • SAML または OpenID 互換の ID プロバイダーがすでにある場合は、 AWS STS AssumeRoleWithSAMLおよび への呼び出しを抽象化する Amazon Cognito ID プール を使用することをお勧めしますAssumeRoleWithWebIdentity。Amazon Cognito は、OpenID や SAML のほか、Facebook、Login with Amazon、Google、Sign in with Apple などのパブリックアイデンティティプロバイダーと統合します。

アイデンティティプロバイダーをお持ちでない場合は、Amazon Cognito ユーザープールの使用を開始できます。Amazon Cognito を Amazon Chime SDK メッセージング機能と共に使用する方法の例については、「Build chat features into your application with Amazon Chime SDK messaging」を参照してください。

あるいは、AWS STS を使用して独自の認証情報供給サービスを作成したり、独自のアイデンティティプロバイダーを構築したりすることもできます。

STS を使用して認証情報を供給する

ActiveDirectory LDAP などの IDP がすでにあり、カスタム認証情報供給サービスを実装する場合、または認証されていない会議の参加者にチャットへのアクセスを許可する場合は、AWS STS AssumeRole API を使用できます。これを行うには、まず Amazon Chime SDK メッセージング SDK ロールを作成します。このロールの作成の詳細については、「IAM ユーザーにアクセス許可を委任するロールの作成」を参照してください。

IAM ロールには、次のような、アプリケーションが使用する Amazon Chime SDK メッセージングアクションに対するアクセス許可があります。

{ "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Action": [ "chime:GetMessagingSessionEndpoint" ], "Resource": [ "*" ] }, { "Effect": "Allow", "Action": [ "chime:SendChannelMessage", "chime:ListChannelMessages", "chime:CreateChannelMembership", "chime:ListChannelMemberships", "chime:DeleteChannelMembership", "chime:CreateChannelModerator", "chime:ListChannelModerators", "chime:DescribeChannelModerator", "chime:CreateChannel", "chime:DescribeChannel", "chime:ListChannels", "chime:DeleteChannel", "chime:RedactChannelMessage", "chime:UpdateChannelMessage", "chime:Connect", "chime:ListChannelBans", "chime:CreateChannelBan", "chime:DeleteChannelBan", "chime:ListChannelMembershipsForAppInstanceUser" "chime:AssociateChannelFlow", "chime:DisassociateChannelFlow", "chime:GetChannelMessageStatus" ], "Resource": [ "{chime_app_instance_arn}/user/${aws:PrincipalTag/my_applications_user_id}", "{chime_app_instance_arn}/channel/*" ] } ] }

この例では、このロールを と呼び出しますChimeMessagingSampleAppUserRole

ユーザー ARN リソースのChimeMessagingSampleAppUserRoleポリシー${my_application_user_id}のセッションタグを書き留めます。このセッションタグは AssumeRole API コールでパラメータ化され、返される認証情報を 1 人のユーザーのアクセス許可に制限します。

AssumeRole および TagSession APIs は、IAM ユーザーなど、既に認証情報が付与されている IAM エンティティを使用して呼び出されます。APIs は、実行ロール などの別の IAM AWS Lambda ロールによって呼び出すこともできます。その IAM アイデンティティには、 TagSessionAssumeRoleおよび を呼び出すためのアクセス許可が必要ですChimeMessagingSampleAppUserRole

{ "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Action": [ "sts:AssumeRole", "sts:TagSession" ], "Resource": "arn:aws:iam::my_aws_account_id:role/ChimeMessagingSampleAppUserRole" } ] }

この例では、このロールをChimeSampleAppServerロール と呼び出します。

STS AssumeRole APIChimeMessagingSampleAppServerRole呼び出すことを許可する信頼ポリシーChimeMessagingSampleAppUserRoleを使用して を設定する必要があります。IAM ロールでの信頼ポリシーの使用の詳細については、「How to use trust policies with IAM roles」を参照してください。 AWS IAM ロールコンソールを使用して、このポリシーを に追加できますChimeMessagingSampleAppUserRole。以下の例は、標準的な信頼関係を示しています。

{ "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Principal": { "AWS":"arn:aws:iam::my_aws_account_id:role/ChimeMessagingSampleAppServerRole" } "Action": "sts:AssumeRole" } ] }

サンプルデプロイでは、Amazon EC2 インスタンス、または AWS Lambda が で起動されますChimeMessagingSampleAppServerRole。その後、サーバーは以下を実行します。

  1. クライアントの認証情報受信リクエストに対して、アプリケーション固有の認証を実行します。

  2. ${aws:PrincipalTag/my_applications_user_id} をパラメータ化するタグを使用して、ChimeMessagingSampleAppUserRole で STS AssumeRole を呼び出します。

  3. AssumeRole 呼び出しで返された認証情報をユーザーに転送します。

以下の例は、ステップ 2 のロールを引き受けるための CLI コマンドを示しています。

aws sts assume-role --role-arn arn:aws:iam::my_aws_account_id:role/ChimeMessagingSampleAppUserRole --role-session-name demo --tags Key=my_applications_user_id,Value=123456789