この記事は公開されてから1年以上経過しています。情報が古い可能性がありますので、ご注意ください。
いわさです。
以前トラスト・ログインを IdP として QuickSight の SSO 機能をセットアップしたことがあります。
今回 Azure Active Directory (AD) を ID プロバイダーとして構成し、Amazon QuickSight へシングルサインオン構成を行う機会がありました。
割と多い組み合わせなのではないかと思い、導入方法を紹介したいと思います。
前提として、AWS では IAM Identity Center (旧: AWS SSO) は使いません。
非 Organizations なシングルアカウントをターゲットに導入します。
Azure AD 構成
まずは Azure AD でサンプルのテナントを作成し、シングルサインオンのセットアップを行います。
Azure AD を QuickSight の IdP として導入する際の特徴としては、AWS と SAML 連携するためのエンタープライズアプリケーションを Azure AD ギャラリーから作成する点と、そのアプリケーションのプロビジョニング機能を使うことで AWS 側の対象ロールへのメンバーのマッピングを Azure 側で管理している点です。
特に後者は SAML 連携を行う際に AWS 側の IAM ロールを IdP 側のユーザー情報とどのように紐付けするか悩ましい点を解消してくれます。
なお、QuickSight における SSO は、結局のところは IAM IdP で構成した SAML 連携を使って、Assume Role する方式なので、QuickSight 用の SSO セットアップというのはほぼやることがありません。
以下のエントリがとても参考になるので、こちらも併せてご確認頂くと良いと思います。
テナント作成
テナント作成は特に今回の構成で考慮すべき点はありません。
いたって普通に作成するだけです。
B2C ではないほうを選択します。
適当にユーザーも作成しておきます。
ここで作成したユーザープリンシパル名をメールアドレスとして、QuickSight へサインイン出来ることをゴールとしています。
AWS へ SAML 連携するためのアプリケーションを追加
Azure AD ギャラリーには AWS と SAML 連携を行うためのいくつかのアプリケーションが既に用意されていますのでそちらを利用します。
対象 Azure AD テナントのエンタープライズアプリケーションにて新しいアプリケーションを追加します。
いくつか AWS 向けのテンプレートは用意されていて、今回は AWS Single-Account Access を選択します。
他にも、AWS IAM Identity Center や AWS ClientVPN などが用意されています。
シングルサインオンの設定
追加したアプリケーションを選択し、シングルサインオンを行うための詳細な設定を行っていきます。
シングルサインオン方式では SAML を選択します。
基本的な SAML 構成については識別子（エンティティID）と応答 URL ともにhttps://signin.aws.amazon.com/samlとしています。
この部分の設定は以下の Azure 公式の導入ドキュメントを参照しています。
複数のインスタンスで複数の識別子を構成する場合は、https://signin.aws.amazon.com/saml#2などを設定を行うことで、複数の Azure AD アプリから複数の AWS アカウントへ SSO なしで構成することも出来ます。
属性とクレームは少し気をつける必要があります。
私は以下４つで今回検証を行いました。
まず、メールアドレスの初回オンボーディングを自動化する場合は QuickSight 用に別途属性を追加しなければいけない場合があるのでご注意ください。
また、https://aws.amazon.com/SAML/Attributes/Roleは AWS 側の IAM IdP と IAM ロールをセットにした情報を指定する形になるのですが、今回は後述のロールのプロビジョニング機能を使うためにデフォルトのuser.assignedrolesを指定したままにしています。
どのタイミングでも良いですが、AWS 側で IdP を構成する際にメタデータが必要になるので、[3] でダウンロードしておきます。
最後に、構成中のアプリケーションにユーザー追加を行います。
テナントに参加させて終わりではなく、アプリケーションへ割り当てする必要があるので忘れずに対応しましょう。
AWS
ID プロバイダーとロールの割り当て
AWS 側では IAM で ID プロバイダーを作成します。
作成時には先程 Azure からダウンロードしたメタデータをアップロードします。
次にロールの割り当てを行います。
このロールでは QuickSight の自動自己プロビジョニングを行う必要があるので必要なアクションを許可する必要があります。
ここでは例としてquicksight:CreateReaderを割り当てることによって、自分を閲覧者として自己プロビジョニングさせることを許可しています。
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"quicksight:CreateReader"
],
"Resource": [
"arn:aws:quicksight::123456789012:user/${aws:userid}"
]
}
]
}QuickSight 構成
先程の IAM IdP 構成でほとんど終わっていて、あとは決まって設定値を QuickSight 管理画面でシングルサインオン構成として入力するだけです。
まずメールアドレスの自動同期は今回は割愛しているので OFF にしています。
こちら ON にすると SAML クレームのhttps://aws.amazon.com/SAML/Attributes/PrincipalTag:Emailが適切に設定されている必要があるのでご注意ください。
URL パラメータ名はRelayStateで SSO URL については Azure AD 用の形式で入力を行う必要があります。
各 IdP ごとに期待される形式は以下にまとまっているので確認してください。
ただし、Azure AD の場合は構成したアプリケーションのプロパティから「ユーザーのアクセス URL」を取得することが出来るので、こちらをそのまま使えば良いです。
ロールのプロビジョニング機能 (オプション)
SAML 構成で固定のロール情報を渡すことも出来なくもないですが、柔軟性がかなり厳しいのでこのプロビジョニング機能を使うとかなり使いやすくなります。
ただしひとつ注意点があり IAM ユーザーを作成してアクセスキーとシークレットを Azure ポータルへ入力する必要があります。ここは出来ればやりたくないなーという方もいるかもしれない。
対象の IAM ユーザーには以下のポリシーだけをアタッチしておきます。
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"iam:ListRoles"
],
"Resource": "*"
}
]
}アクセスキーとシークレットを Azure ポータルのプロビジョニング機能へ登録すると、AWS アカウントからロールを取得し Azure テナント上の割当メンバーに SSO の際の IAM ロールを割り当て出来るようになります。
厳密には IAM IdP が AssumeRole するロール情報を Azure 側から指定しているだけなのですが、あたかも AWS 上のロールを Azure ユーザーに割当するような操作感になっていて、これはなかなか良い機能だなと思いました。
サインインしてみる
さて、準備完了です。
QuickSight サインイン画面で QuickSight アカウント名を入力します。（≠ QuickSight ユーザー）
そうすると Azure AD のサインイン画面へ遷移するので、対象テナント・対象アプリに関連付けしたメンバーでサインインしましょう。
メールアドレスを入力する自己プロビジョニング画面に遷移出来れば成功です。
以下のように閲覧者権限でダッシュボードが利用出来るようになっているはずです。
さいごに
本日は Azure AD を ID プロバイダーとして Amazon QuickSight へシングルサインオンしてみました。
Azure AD を IdP として利用するケースはやはり多いので、一度 QuickSight のシングルサインオン構成で試しておきたいと思っていたのですが、ようやく試す機会を得ることが出来ました。
所感としては IdP ごとにシングルサインオンを補完する機能やデフォルトテンプレートがあって手順が全く違っているなぁと思いました。もし QuickSight で SSO を行いたいというときも、IdP ごとに実は実現が大変だったり手間が多かったりなどのリスクがありそうだという点を事前に認識しておくと良いなと思いました。
6
