いつもお世話になっております。
埋め込みURLでのSSO認証の挙動について質問させてください。
QuickSightのSSO認証（Azure AD）を設定しているのですが、
独自サイトを構築し、トップページにQuickSightダッシュボードの１Click埋め込みURLを埋め込んでいます。
初回アクセス時はQuickSight以外でSSO認証後にトップページを開くと埋め込んだダッシュボードが表示されるのですが、翌日、QuickSight以外でSSO認証後にトップページを開くと、以下のメッセージが表示されてしまいます。
他でSSO認証しているにも関わらず、QuickSightのSSO認証のセッションが切れたままとなっているのは何故でしょうか？ また、これを回避する方法はありますでしょうか？
このメッセージが表示されると、一度ログアウトして再認証する必要があり、非常に煩わしいです。
@cs_saka さん、ご質問ありがとうございます。
現状の構成としては以下のように理解しましたが、認識に誤りがあればご指摘ください。
初回アクセス時はQuickSight以外でSSO認証後にトップページを開くと埋め込んだダッシュボードが表示されるのですが、翌日、QuickSight以外でSSO認証後にトップページを開くと、以下のメッセージが表示されてしまいます。
初回アクセスおよび翌日ともにQuickSight以外でSSO認証してからQuickSightにアクセスしたとありますが、これはQuickSightやAWSマネジメントコンソールのようなAWS IAMフェデレーションを経由するアプリケーションではない、何か別のものということでしょうか。AWS IAMフェデレーションを行っていれば、当該エラーは表示されないものと思いますので、こちらも認識に誤りがあればご指摘ください。
他でSSO認証しているにも関わらず、QuickSightのSSO認証のセッションが切れたままとなっているのは何故でしょうか？ また、これを回避する方法はありますでしょうか？
QuickSightではSAMLフェデレーション構成時でも、SAMLには依存しない形で12時間固定のセッションを払い出しています。一度QuickSightにアクセスしてから12時間以上経過した後、AWS IAMとのSAMLフェデレーションのサインインを経由せず、1-click登録済み埋め込みで特定のダッシュボードURLに直接にアクセスした場合、セッションが失効しているため、添付のAWSセッションエラーの画面が表示される流れとなります。
AWS IAMとのSAMLフェデレーションを意識していない純粋なビジネスユーザーの場合、おっしゃるようにこの挙動は煩わしく混乱を招きやすいものかと思います。この挙動を回避するには以下のいずれかのアプローチが検討できます。
なお、現時点では既存のQuickSightサブスクリプションの認証方式を変更する手段は提供されていないため、1. については別AWSアカウントで認証方式をIAM Identity Centerにした新規のQuickSightサブスクリプションを作成し、既存のアセットをExport APIを利用して移行する必要があるのですが、権限の付け替えなど入念な検討と準備が必要となり難易度が高くなります。
2.については埋め込み先のアプリケーションで事前にユーザーを認証していることを前提に、APIで登録済みユーザー向けのダッシュボードURLを発行する形となります。既存の埋め込み先アプリケーションで認証を行っていない場合にはアプリ側で改修の必要があるのですが、既存のQuickSightアカウントはそのまま利用できるため、1.よりは現実的かと思います。
以上、ご検討のほどよろしくお願いいたします。
@ytakahr さん
ご回答ありがとうございます
初回アクセスおよび翌日ともにQuickSight以外でSSO認証してからQuickSightにアクセスしたとありますが、これはQuickSightやAWSマネジメントコンソールのようなAWS IAMフェデレーションを経由するアプリケーションではない、何か別のものということでしょうか。AWS IAMフェデレーションを行っていれば、当該エラーは表示されないものと思いますので、こちらも認識に誤りがあればご指摘ください。
はい、AWS IAMフェデレーションを経由するアプリケーションではないので、ご指摘の挙動となることを理解しました。
また、その他についてもご認識の内容で齟齬はありません。
アプローチ提示いただきましたが、
２については、埋め込みダッシュボード表示時の認証を利用してログインさせようとしているため、現在の構成では回避が難しいと認識しました。
１については、検討はしたいと思いますが、AWSアカウントの移行など大掛かりな作業が発生するため、実現は難しいように思います。
一旦トップメニューのみ、QuickSightダッシュボードを経由させるなど、別のアプローチを含め検討したいと思います。
@cs_saka さん、早々にご確認いただきありがとうございます。
別のアプローチも含めご検討いただけるとのことで承知しました。
一旦、本トピックについては上記の投稿をSolutionとしてクローズしますが、検討の過程でご不明点など出てきましたら、気軽にご相談ください。
１についてですが、セッションエラーメッセージの回避に繋がらないのですが、
どのように解消される見込みなのでしょうか？それを含めて検証が必要、ということでしょうか？
クローズ後に申し訳ございませんが、ご回答いただけると助かります
@cs_saka さん、ご質問ありがとうございます。
1はIAM Identity CenterからAWSアカウントへのフェデレーションではなく、以下のようにアプリケーションとして直接QuickSightにアクセスいただく必要があります。
こちらをお試しいただいても12時間経過後のセッションエラーメッセージは引き続き表示されたということでしょうか？
ご回答ありがとうございます
IAM Identity Centerはまだ利用したことが無いためイメージできておりませんでしたが、
Azure ADのアプリからの遷移と同等と理解しました。
BlackBelt onlineの資料を抜粋させていただきますが、
QuickSight埋め込みURLは、下図左のSP Initiated SSOだと思いますが、
右のIdP Initiated SSOにして、IdPを必ず経由する流れにする必要があると思っています。
これは、IAM Identity Centerに切り替えた場合でも同じでしょうか？
IAM Identity Centerはまだ利用したことが無いためイメージできておりませんでしたが、
Azure ADのアプリからの遷移と同等と理解しました。
現在ご利用になっているAzure ADの構成はAzure ADとAWS IAMをSAMLフェデレーションし、SAMLフェデレーションで引き受けたIAMロールでQuickSightを利用する形式になっているはずです（＝IAMフェデレーション）。
IAM Identity Centerの利用方法としては、IAM IDC自身がSAML IdPとしてふるまいAWS IAMとSAMLフェデレーションを行い、上記と同様にIAMロールでQuickSightを利用するIAMフェデレーションの形式と、IAM Identity CenterのOAuth 2.0アプリケーションとしてQuickSightを構成する形式（“First Party Integration”）の2種類があり、今回ご相談いただいたセッションエラーを回避することができるのは後者のみです。IAMフェデレーションとは異なる点にご注意ください。
後者を構成するにはQuickSightの新規サブスクリプションで認証方式としてIAM Identity Centerを選ぶ必要があります。なお、IAM Identity Centerのアイデンティティソースとしては引き続きAzure ADを利用することが可能です。
ややこしいのですが、まとめると以下のようなイメージです。
Azure AD/Entra ID [SAML IdP]→IAM Identity Center [SAML SP] →QuickSight [OAuth 2.0アプリケーション]
QuickSight埋め込みURLは、下図左のSP Initiated SSOだと思いますが、
1-click登録済み埋め込みの場合にはご認識の通りSP Initiated SSOです。
（QuickSightの管理画面でSSO設定をしておくことで、埋め込み画面にアクセスしたときにQuickSightが自動的にIdPにリダイレクトする挙動）
右のIdP Initiated SSOにして、IdPを必ず経由する流れにする必要があると思っています。
API埋め込みのことを意図されているようでしたら違います。API埋め込みではアプリケーション側で事前に認証していることを前提にAPIでダッシュボード表示用のURLを発行するため、認証はアプリケーション側での制御となります。埋め込みについては参考リンクが詳しいのでご覧ください。[1]
これは、IAM Identity Centerに切り替えた場合でも同じでしょうか？
IAM Identity Centerの場合、IAM Identity Centerのポータルからのアクセス（IdP-initiated）、QuickSightからのアクセス（SP-initiated）ともに可能です。
