トラスト・ログインを使ってQuickSight SSOをセットアップしてみた

いわさです。

Amazon QuickSightはシングルサインオンの設定が可能です。
AssumeRoleWithSAMLで得た認証情報を使ってQuickSightアプリケーションへアクセスします。

AWS公式ドキュメントではOktaを使ったSSOセットアップ手順が公開されています。

この度トラスト・ログインでのセットアップを行ったので、手順など残しておきます。
トラスト・ログインではAWS統合が用意されているので、純粋なSAML設定より楽だと思います。

トラスト・ログインについては以下を参照してください。

前提

トラスト・ログインでのアカウント作成とQuickSightアカウントのサブスクライブが完了していることを前提とします。

設定手順

まず、トラスト・ログインでアプリケーションを作成します。
今回の手順では"アプリ登録"で進めます。

SAMLアプリ登録でも可能なのですが、アプリ登録からだとAWS SAML認証のテンプレートが用意されているのでとても簡単です。

アプリケーションの名前を設定したら、メタデータをダウンロードします。

AWSのマネージメントコンソールに移動し、IAMからIDプロバイダを作成します。

プロバイダのタイプはSAMLを選択してください。
メタデータドキュメントに先程トラスト・ログインからダウンロードしたXMLファイルを指定します。

プロバイダが作成出来たらロールを割り当てます。

以下を指定してください。

項目	設定値
属性	SAML:aud
値	https://signin.aws.amazon.com/saml

信頼ポリシーに使われます。

ロールへのポリシーは以下を設定します。

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Effect": "Allow",
            "Action": [
                "quicksight:CreateReader"
            ],
            "Resource": [
                "arn:aws:quicksight::123456789012:user/${aws:userid}"
            ]
        }
    ]
}

上記は閲覧者用のポリシーです。 ハイライト行を変更することで、管理者（CreateAdmin）や作成者（CreateUser）への自己プロビジョニングも可能になります。
ただし、管理者の場合はAPIアクセス権限も付与しないといくつかのQuickSight管理機能でエラーになります。
詳しくは以下を参照しながらポリシーを設定すると良いと思います。

ポリシー及びロールが作成出来たら、以下のロールARNとプロバイダーARNをコピーしてください。
トラスト・ログインの設定値として使用します。

トラスト・ログインのアプリケーション作成画面でSP認証成功後の移行URLにhttps://quicksight.aws.amazon.com/sn/startを指定します。

SAML属性に先程のロールARNとプロバイダーARNをカンマ区切りで設定してください。

例
arn:aws:iam::999999999999:role/trustlogin-reader,arn:aws:iam::999999999999:saml-provider/trustlogin

これでトラスト・ログイン側のアプリケーション登録は完了ですが、トラスト・ログインの組織メンバーなら誰でもQuickSightへアクセスできるわけではありません。
IdP側でアクセス可能なメンバーの管理を行う必要があります。

作成したアプリケーションにメンバーを追加してください。

AWSマネジメントコンソールに戻り、QuickSight側でSSOを有効化して完了です。

管理メニューからSSO設定を開き、SSO URLにトラスト・ログインのIDプロバイダーURLを、URLパラメータ名にRelayStateを入力してください。

赤枠のURLでSSOのテストを行い、問題なければリダイレクトのステータスをONにします。

動作確認（メンバー）

以下へアクセスしてください。

https://quicksight.aws.amazon.com/sn/auth/signin?directory_alias=iwasa-quicksight
（ディレクトリエイリアスをURLで指定することで入力済みに出来ます。）

今まではマネジメントコンソールからのアクセス以外では、以下のQuickSightログイン画面を使っていたと思います。

これが、トラスト・ログインのログイン画面になりました。

認証後、QuickSightに自動で遷移します。

この時点でトラスト・ログインから渡された情報で認証自体はされているのですが、自己プロビジョニング時の初回はQuickSight用にメールアドレスが要求されます。

メールアドレス登録後、無事閲覧者権限で参照が出来ました。

トラスト・ログインログイン後の、アプリケーション一覧からも遷移出来ます。

CloudTrailでのトレースも出来ています。

動作確認（非メンバー）

アプリケーションの対象外であるメンバーでアクセスしてみると…

トラスト・ログインにログインできてもQuickSightへのアクセスは拒否されました。

さいごに

簡単にセットアップすることが出来ました。
今回はトラスト・ログインで用意されたテンプレートを利用したためSAMLの属性なども意識していなかったので、他のIdPへ応用する際は考慮しなければいけない点が出てくると思います。
そのあたりを踏まえてSAMLアプリ登録を行った場合の手順も記事にしようと思います。

セットアップに失敗して、サインインできなくなった場合ですが、以下のパラメータでIdP遷移を回避し、直接QuickSightログイン試みることが出来ますので試してみてください。

https://quicksight.aws.amazon.com/sn/auth/signin?enable-sso=0