本文為英文版的機器翻譯版本，如內容有任何歧義或不一致之處，概以英文版為準。

在 Amazon 中為聯合身分使用者設定電子郵件同步 QuickSight

在 Amazon QuickSight Enterprise Edition 中，身為管理員，您可以限制新使用者在透過身分提供者 (IdP) 直接佈建時使用個人電子郵件地址 QuickSight。 QuickSight 接著，在將新使用者佈建至您的帳戶時使用透過 IdP 傳遞的預先設定電子郵件地址。例如，您可以讓它使用，以便在透過 IdP 將使用者佈建至 QuickSight 您的帳戶時，只會使用公司指派的電子郵件地址。

當您為 中的聯合身分使用者設定電子郵件同步時 QuickSight，第一次登入您 QuickSight 帳戶的使用者已預先指派電子郵件地址。這些可用於註冊他們的帳戶。使用這種方法，使用者可以透過輸入電子郵件地址手動繞過。此外，使用者無法使用可能與您 (系統管理員) 指定的電子郵件地址不同的電子郵件地址。

QuickSight 支援透過支援 SAML或 OpenID Connect (OIDC) 身分驗證的 IdP 佈建。若要在透過 IdP 佈建時為新使用者設定電子郵件地址，請更新其與 AssumeRoleWithSAML或 搭配使用之IAM角色的信任關係AssumeRoleWithWebIdentity。然後，您可以在其 SAML IdP 中新增屬性或OIDC權杖。最後，您在 中開啟聯合身分使用者的電子郵件同步 QuickSight。

下列程序詳細說明了這些步驟。

步驟 1：使用 更新IAM角色的信任關係 AssumeRoleWithSAML 或 AssumeRoleWithWebIdentity

您可以設定使用者在透過 IdP 佈建時使用的電子郵件地址 QuickSight。若要這樣做，請將 sts:TagSession動作新增至您搭配 AssumeRoleWithSAML或 使用之IAM角色的信任關係AssumeRoleWithWebIdentity。透過這樣做，您可以在使用者擔任該角色時傳遞 principal 標籤。

下列範例說明 IdP 為 Okta 的更新IAM角色。若要使用此範例，請使用服務供應商ARN的 更新 Federated Amazon Resource Name (ARN)。您可以使用 AWS 和 IdP 服務特定資訊取代紅色的項目。

{
    "Version": "2012-10-17",
    "Statement": [
    {
        "Effect": "Allow",
        "Principal": {
        "Federated": "arn:aws:iam::account-id:saml-provider/Okta"
        },
        "Action": "sts:AssumeRoleWithSAML",
        "Condition": {
        "StringEquals": {
            "SAML:aud": "https://signin.aws.amazon.com/saml"
        }
        }
    },
    {
        "Effect": "Allow",
        "Principal": {
        "Federated": "arn:aws:iam::account-id:saml-provider/Okta"
        },
        "Action": "sts:TagSession",
        "Condition": {
        "StringLike": {
            "aws:RequestTag/Email": "*"
        }
        }
    }
    ]
    }

步驟 2：為 IdP 中的IAM主體標籤新增SAML屬性或OIDC權杖

如上節所述更新IAM角色的信任關係後，請在 IdP 中新增IAMPrincipal標籤的SAML屬性或OIDC權杖。

下列範例說明 SAML 屬性和權OIDC杖。若要使用這些範例，請將電子郵件地址取代為 IdP 中指向使用者電子郵件地址的變數。您可以使用您的資訊取代以紅色反白顯示的項目。

步驟 3：在 中開啟聯合身分使用者的電子郵件同步 QuickSight

如上所述，更新IAM角色的信任關係，並在 IdP 中新增IAMPrincipal標籤的SAML屬性或OIDC權杖。然後開啟 中聯合身分使用者的電子郵件同步 QuickSight ，如下列程序所述。