AWS STS Auth

​

認証フロー

​

前提条件

• アプリケーションが、Amazon EC2 インスタンスプロファイル、Amazon ECS タスクロール、AWS Lambda 実行ロール、AWS STS を通じて引き受けたロールなどの AWS IAM ロールで実行されていること。永続的な IAM ユーザーの認証情報はサポートされていません。
• アプリケーションが、Signature Version 4 署名を提供する AWS SDK を使用していること。この記事の例では、Python の botocore ライブラリを使用しています。
• API キーを作成する権限を持ち、Settings > Account > API keys にアクセスできること。
• ワークスペースをホストしているデータセンターを特定していること。データセンターを参照してください。

​

リージョンごとの AWS STS ホスト

​

ステップ 1: AWS STS Auth API キーを作成する

​

認証情報の取り扱い

• MOE-APPKEY には Workspace ID が格納されます。この値は秘密情報ではなく、すべてのリクエストに含める必要があります。
• MOE-APPSECRET は 1 つのキーに固有です。パスワードとして扱い、シークレットマネージャーに保存して、ソース管理に含めないでください。
• MOE-APPSECRET は、リクエストを 1 つの MoEngage キーとその API アクセスに結び付けます。AWS ロールはチームや環境間で共有されることが多いため、AWS の署名だけでは対象のキーを特定できません。
• MOE-APPSECRET は、リクエストに署名する AWS 認証情報とは異なり、有効期限がなく、自動でローテーションされることもありません。
• MOE-APPSECRET は作成後も取得できます。キーの メニューから View key details を選択すると、値が再度表示されます。
• シークレットをローテーションするには、API キーダッシュボードで Regenerate key を使用します。再生成はキーのロール ARN や API アクセスには影響せず、以前のシークレットは直ちに使用できなくなります。

​

ステップ 2: GetCallerIdentity リクエストに署名する

import boto3
from botocore.awsrequest import AWSRequest
from botocore.auth import SigV4Auth

# boto3 reads your role's temporary credentials from the Amazon EC2 instance
# profile, Amazon ECS task role, or AWS Lambda execution role automatically.
session = boto3.Session()
credentials = session.get_credentials().get_frozen_credentials()

region = "ap-south-1"  # AWS region for your MoEngage data center
moe_app_key = "YOUR_WORKSPACE_ID"
moe_app_secret = "YOUR_MOE_APPSECRET"

request = AWSRequest(
    method="POST",
    url=f"https://sts.{region}.amazonaws.com/",
    data="Action=GetCallerIdentity&Version=2011-06-15",
    headers={
        "MOE-APPKEY": moe_app_key,        # Added before signing
        "MOE-APPSECRET": moe_app_secret,  # Added before signing
        # Content-Type intentionally omitted
    },
)

SigV4Auth(credentials, "sts", region).add_auth(request)
prepared = request.prepare()

​

ステップ 3: MoEngage Public API を呼び出す

curl --request POST \
  --url https://api-{dc}.moengage.com/v1/customer/YOUR_WORKSPACE_ID \
  --header 'Authorization: AWS4-HMAC-SHA256 Credential=YOUR_SIGNED_CREDENTIAL, SignedHeaders=host;moe-appkey;moe-appsecret;x-amz-date;x-amz-security-token, Signature=YOUR_CALCULATED_SIGNATURE' \
  --header 'MOE-APPKEY: YOUR_WORKSPACE_ID' \
  --header 'MOE-APPSECRET: YOUR_MOE_APPSECRET' \
  --header 'X-Amz-Date: YOUR_SIGNING_TIMESTAMP' \
  --header 'X-Amz-Security-Token: YOUR_SESSION_TOKEN' \
  --header 'Content-Type: application/json' \
  --data '{ "type": "customer", "customer_id": "user_12345" }'

• {dc} をデータセンター番号に置き換え、各プレースホルダーを ステップ 2 で生成された値に置き換えてください。
• Content-Type は、MoEngage の呼び出しでは必須ですが、署名済みの GetCallerIdentity リクエストでは指定できません。
• 呼び出し可能なエンドポイントについては、API ドキュメントを参照してください。リクエスト制限とペイロードの上限については、Rate Limits を参照してください。

​

認証エラー

​

トラブルシューティング

​

MoEngage が解決する ARN を確認する

aws sts get-caller-identity

{
    "UserId": "AROAEXAMPLEUSERID:data-pipeline-prod",
    "Account": "123456789012",
    "Arn": "arn:aws:sts::123456789012:assumed-role/MoEngageIngestionRole/data-pipeline-prod"
}

​

ロール ARN のワイルドカード

• 1 つのエントリで使用できる * は 1 つだけで、最後の文字としてのみ使用できます。assumed-role/My*Role や、ワイルドカードを 2 つ含むエントリは無効です。
• ロール名には、ワイルドカードの前に少なくとも 1 文字が含まれている必要があります。そのため、assumed-role/* は無効です。

​

推奨されるプラクティス

• 本番トラフィックをルーティングする前に、ステージング用のロール ARN を登録したステージング専用キーで検証してください。
• 移行期間中は、Basic Auth または OAuth 2.0 の認証情報を有効なままにしてください。切り替え作業は必要ありません。
• 署名と送信は同じ操作で行ってください。署名をキャッシュしないでください。
• MOE-APPSECRET はシークレットマネージャーに保存し、クライアントサイドのコードに含めないでください。
• ロールごとに必要な API アクセスのレベルが異なる場合は、別々のキーを作成してください。

​

連携チェックリスト

• アプリケーションが、引き受けたロールの一時的な認証情報で署名している。
• STS ホストが MoEngage のデータセンターと一致している。
• MOE-APPKEY と MOE-APPSECRET が署名前に追加されている。
• 署名済みリクエストに Content-Type ヘッダーが含まれていない。
• 実行時に解決される ARN が、正確なセッション名または * ワイルドカードでキーに登録されている。
• キーに、連携に必要な API アクセスが設定されている。
• MOE-APPSECRET がシークレットマネージャーに保存されている。
• 署名済みのヘッダーを使用した MoEngage Public API の呼び出しが成功する。
• 追加の認証ヘッダーが含まれていない。

​

よくある質問

​

関連記事

​

サポートへのお問い合わせ