Cookie の設定を選択する

当社は、当社のサイトおよびサービスを提供するために必要な必須 Cookie および類似のツールを使用しています。当社は、パフォーマンス Cookie を使用して匿名の統計情報を収集することで、お客様が当社のサイトをどのように利用しているかを把握し、改善に役立てています。必須 Cookie は無効化できませんが、[カスタマイズ] または [拒否] をクリックしてパフォーマンス Cookie を拒否することはできます。

お客様が同意した場合、AWS および承認された第三者は、Cookie を使用して便利なサイト機能を提供したり、お客様の選択を記憶したり、関連する広告を含む関連コンテンツを表示したりします。すべての必須ではない Cookie を受け入れるか拒否するには、[受け入れる] または [拒否] をクリックしてください。より詳細な選択を行うには、[カスタマイズ] をクリックしてください。

Amazon Chime SDK メッセージング用のエンドユーザークライアントアプリケーションの認証

フォーカスモード
Amazon Chime SDK メッセージング用のエンドユーザークライアントアプリケーションの認証 - Amazon Chime SDK

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

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

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

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

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

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

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

  • SAML または OpenID と互換性のあるアイデンティティプロバイダーを既にお持ちの場合は、Amazon Cognito アイデンティティプールを使用することをお勧めします。これにより、 AWS STS AssumeRoleWithSAML および 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 コールでパラメータ化され、単一ユーザーのアクセス許可に返される認証情報を制限します。

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

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

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

ChimeMessagingSampleAppServerRoleSTS AssumeRole API を呼び出すことを許可する信頼ポリシーを使用して 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

このページの内容

プライバシーサイト規約Cookie の設定
© 2025, Amazon Web Services, Inc. or its affiliates.All rights reserved.