QuickSightユーザーをプロビジョニング時のイベントは手動ユーザー登録とSSOで発生イベントが違うという話

2022.03.10

この記事は公開されてから1年以上経過しています。情報が古い可能性がありますので、ご注意ください。

いわさです。

QuickSight上でのユーザー作成イベントを検知するためにEventBridgeでパターンを設定していたのですが、外部IdPによるシングルサインオン(SSO)を使った場合にうまく動作しませんでした。
結論としては登録パターンによって発生するイベントが全然違っていたということなのですが、QuickSightのユーザー登録からEventBridgeを利用するパターンの参考になるかなと思い、記事にしておきます。

最初設定していたイベントパターン

QuickSightでユーザー登録を行うにはRegisterUserを使います。
そこで当初は以下のようにイベントパターンを指定していました。

{
  "source": ["aws.quicksight"],
  "detail-type": ["AWS API Call via CloudTrail"],
  "detail": {
    "eventSource": ["quicksight.amazonaws.com"],
    "eventName": ["RegisterUser"]
  }
}

ところが、以下のような構成で外部IDプロバイダーからSSOで新規ユーザーをプロビジョニングさせるとこのイベントが発生していませんでした。

原因

通常のユーザー登録とSSOでのプロビジョニング時でデータイベントが全然違っていたことが原因でした。

通常イベント(主要部分のみ抜粋)

{
    "version": "0",
    "id": "66e4d212-85bf-c002-a345-3867a184465d",
    "detail-type": "AWS API Call via CloudTrail",
    "source": "aws.quicksight",
    "account": "123456789012",
    "detail": {
        "eventSource": "http://quicksight.amazonaws.com",
        "eventName": "RegisterUser",
        "userAgent": "aws-cli/2.4.23 Python/3.8.8 Darwin/20.6.0 exe/x86_64 prompt/off command/quicksight.register-user",
        "requestParameters": {
            "identityType": "QUICKSIGHT",
            "email": "hoge@example.com",
            "userRole": "READER",
            "awsAccountId": "123456789012",
            "namespace": "default",
            "userName": "cli1"
        },
        "responseElements": {
            "user": {
                "arn": "arn:aws:quicksight:ap-northeast-1:123456789012:user/default/cli1",
                "userName": "cli1",
                "email": "hoge@example.com",
                "role": "READER",
                "identityType": "QUICKSIGHT",
                "active": false,
                "principalId": "user/d-95671d86a5/8c187c18-1329-4357-a8a8-ba51bbb08b90"
            },
            "userInvitationUrl": "https://ap-northeast-1.signin.aws.amazon.com/inviteuser?hogehoge",
        },
        "eventType": "AwsApiCall",
        "managementEvent": true,
        "eventCategory": "Management"
    }
}

SSOイベント(主要部分のみ抜粋)

{
    "version": "0",
    "id": "7166a78d-181e-bffc-6707-a97a0c99e5e3",
    "detail-type": "AWS Service Event via CloudTrail",
    "source": "aws.quicksight",
    "detail": {
        "eventVersion": "1.08",
        "eventSource": "http://quicksight.amazonaws.com",
        "eventName": "CreateUser",
        "eventType": "AwsServiceEvent",
        "managementEvent": true,
        "serviceEventDetails": {
            "eventRequestDetails": {
                "role": "READER",
                "userName": "trustlogin-reader2:iwasa.takahito+trust3@example.com"
            },
            "eventResponseDetails": {
                "userId": "arn:aws:sts::123456789012:assumed-role/trustlogin-reader2/iwasa.takahito+trust3@example.com"
            }
        },
        "eventCategory": "Management"
    }
}

SSOでのプロビジョニング時はAWS Service EventによるCreateUserが発生していました。

SSOプロビジョニングユーザーを拾うイベントパターン

以上から、SSOプロビジョニングイベントのイベントパターンは以下のようになります。

{
  "source": ["aws.quicksight"],
  "detail-type": ["AWS Service Event via CloudTrail"],
  "detail": {
    "eventSource": ["quicksight.amazonaws.com"],
    "eventName": ["CreateUser"]
  }
}

また、後続のLambdaやStep Functionsなどで処理する場合のユーザー名取得元などもRegisterUserとは構成が異なるので注意が必要です。

さいごに

SSOプロビジョニング時のイベントの違いについて紹介しました。

まさか構造が違うとは。
ユーザー作成時の初期化処理などを想定していたのですが、このあたりはパターンごとの考慮が必要なりなりそうですね。

QuickSightとEventBridgeの連携例をあまり見たことがなかったので、どなたかの参考になれば幸いです。