Amazon Quick on DesktopがIAM Identity Centerで動かない理由

Transcript

1. A m a zon Q u i c k o n D e s k t op が I A M Id e n t it y C e n t e r で 動 か な い 理由 外部IdPなしでEnterprise Sign-Inを通すまで IoT・ライフソリューション新事業推進センター 小川 雄喜 2026/9/10(木) AWS Community Builder Kansai主催 Amazon Quick & Kiro Festival!!
2. スピーカー紹介 【所属＆経歴】 2010～2019 研究所 • クラウドどころかコーディングもしていませんでした・・・ 2019～2020 アメリカでの海外研修 • AWSを初めて触りました おがわ ゆうき 小川 雄喜 • AWS Community Builders 2025/2026 • Japan All AWS Certifications Engineers 2025/2026 • Japan AWS Top Engineers 2020～2026 新設組織でプラットフォーム開発 • 初めは仕様書作成だけ、そこからコーディング→クラウドアーキ テクチャ設計と広がっていきました • 新設組織だったため、社内ハッカソンやLT会などの盛り上げイ ベントも担当するようになりました 2026.4～ CCoE/AICoEの専任 2025/2026 • CCoE：主にAWSを中心とした勉強会、各種SaaS製品のチー ム展開など • AICoE：Kiroを中心としたAI講習会を開催 ©Mitsubishi Electric Corporation 2
3. Amazon Quickとは？ Amazon Quick とは、生成 AI を活用した包括的なビジネスプラットフォーム。 機械学習の専門知識を必要とせず、多様なデータソースに接続し、 インタラクティブなダッシュボードを作成したり、AI エージェントによる高度な自動化を達成できます。 Amazon Quick インサイト DWH インメモリDB データの可視化 自動化 インテグレーション ©Mitsubishi Electric Corporation AIエージェント データ分析 3
4. Amazon Quick(Web)は、IAM Identity CenterをIdPにできる Enterprise Sign-inにより、組織OIDC IdPと連携したSSOログインが可能！ 組織で使っている 外部IdPを利用できる！ SSOログイン Microsoft Entra ID Google Workspace Ping Identity Okta 外部IdPを使わず、AWSサービス内の AWS環境に閉じて ユーザー発行できる！ IAM Identity Center(IIC)を使って ログインすることも可能 AWS IAM Identity Center ©Mitsubishi Electric Corporation 4
5. Quick on Desktopは、IICだけではサインインが通らない！ • Quick on Desktopは、OIDC IdPに対して、 Authorization Code + PKCEフローで認証を行う • しかし、IICは標準OIDCフローを公開していないため、 IICを直接Quick on DesktopのOIDC IdPに指定 できない • /authorize や /token などは外部未公開 • OAuth 2.0 Device Authorization Grant (RFC 8628のみ実装) • また、AWS公式でも、 IIC利用時のセットアップ手順は 現時点で準備されていない！ ©Mitsubishi Electric Corporation 5
6. Quick on Desktop が要求する認証フロー IdPが /authorize と /token を公開している必要がある ©Mitsubishi Electric Corporation 6
7. じゃあ、Cognito User Pool を OIDC IdP にしたらいける？ Cognito は、 offline_access スコープ非対応 GET https://idp.example.com/oauth2/authorize ?client_id=<quick-desktop-client-id> • リフレッシュトークンを得るために offline_access スコープをリクエスト &response_type=code • Cognitoは offline_access を含むリクエストを拒否してしまう &scope=openid profile email offline_access • Cognitoは openid/profile/emailなどを標準スコープとして対応 &code_challenge_method=S256 &redirect_uri=<registered-redirect-uri> &code_challenge=<code_challenge> &state=<state> Authorization Code + PKCE 認可フローリクエスト /authorize へのリクエストから、offline_access スコープだけ除去すればよい？ • Cognitoは、スコープではなくグラントとしてリフレッシュトークンを返し、Quickはリフレッシュ トークンが応答されることで満足 • リフレッシュトークンはグラントタイプで決まり、Cognito と Quick はAuthorization Code + PKCE で対応（IICは Device Grantのみだった） • リフレッシュトークンの利用は offline_access のユースケースに限定されず、認可サーバーはこ の仕様の範囲外の文脈でリフレッシュトークンを付与してもよい（OpenID Connect Coreより） ©Mitsubishi Electric Corporation 7
8. 実装アーキテクチャ API GatewayをQuickからのエンドポイントとし、Lambdaでスコープ除去 • デスクトップアプリで、Enterprise Sign-In（Continue with SSO）を実行 • 管理コンソールのExtension accessで、認証エンドポイントとトークンエンドポイントにAPI Gatewayの URLを指定。発行者URL、JWKS URI、クライアントIDはCognitoを指している Amazon Quick on Desktop • LambdaをHTTPSで公開。Lambda Function URLでも対応可。 • 必要に応じて、CloudFrontを前段においてWAF適用など、セキュリティ要件追加 Amazon API Gateway • /oauth2/authorize：offline_accessスコープを除去して、Cognitoへ302リダイレクト • /oauth2/token：Cognitoへの中継 • /oauth2/userInfo：AuthorizationヘッダーごとCognitoへ中継 AWS Lambda • /.well-known/*：OIDCメタデータ応答、JWKS中継 • パブリッククライアント（シークレットなし）。サインイン画面の提供。 Amazon Cognito ©Mitsubishi Electric Corporation 8
9. Cognito と IIC をSAMLで連携すれば、ユーザー管理は楽チン！ • CognitoとIICをSAML 2.0で接続し、Cognitoでのユーザー管理は不要 • ユーザー管理はIAM Identity Centerだけで完結する Amazon Cognito AWS IAM Identity Center AWSアカウントによっては、IIC のアプリ追加で SAML 選択画面がない？ SAML 2.0を選択できるAWSアカウント ©Mitsubishi Electric Corporation 外部OAuth2.0の設定が求められるAWSアカウント 9
10. IAM Identity Center って2種類あるんやで？ • カスタム SAML 2.0 アプリは組織インスタンスでしか作れない • 次のコマンドで管理アカウントのIDを確認できるため、自分のアカウントIDと比較して判断 aws organizations describe-organization --query Organization.MasterAccountId ©Mitsubishi Electric Corporation 10
11. 実装上でのハマりポイント 1 Extension access と Extension は別物 Quick Web上の管理コンソールで Extension access（OIDC接続情報）を登録し、 Quick Web上の通常画面で Extension（拡張機能）を作成する。 特にExtension作成を忘れると、Quick Desktopのエンタープライズサインインができない。 2 メールアドレスは大文字小文字まで完全一致 QuickとCognitoは別々のサービスで、情報を共有しているわけではない。 Quick上が Foo.Bar@test.co.jp 、Cognito 側が foo.bar@test.co.jp だと、認証は成功するが “User not found” となる。 Quickがトークンのemailをもとに、Quickのユーザー一覧から同じEmailを持つユーザーを探すが、見つからないため。 3 ユーザー追加は3か所必要 QuickがIAMフェデレーション方式のため、①IIC → ②Quick → ③Cognito のすべてにユーザー登録が必要。 組織インスタンスのIICでSMAL連携すれば、③Cognitoは不要となる。 アカウントインスタンスで、Quick利用人数が増えるならスクリプト化を推奨。 ©Mitsubishi Electric Corporation 11
12. 余談： 課金はどこに乗るのか 管理アカウントに SAML アプリを作っても、課金先はメンバーアカウントのまま 項目 課金先 Quick のライセンス Quickサブスクリプションを持つメンバーアカウント IAM Identity Center 無料 管理アカウントの SAML アプリ 無料（認証を仲介するだけでQuickリソースは作られない） Cognito / API Gateway / Lambda メンバーアカウント（ほぼ無視できる額） ©Mitsubishi Electric Corporation 12
13. まとめ Quick on Desktop で IIC ログインができなかった理由 • IAM Identity Center は Device Authorization Grant のみ公開 • Cognito は offline_access をサポートしていない 実装内容 • Quickから API Gateway を呼び出し、連携した Lambdaで offline_access を除去 • 組織インスタンスであれば、Cognito と IIC SAML で連携 • メンバーアカウントであれば、Cognito でユーザー管理し、IICとQuickのメールアドレスを一致させる Quick展開について • Quickを社内・部門内で広めるなら、会社利用の外部IdPを利用したほうが良い • KiroやQuickとツールが増えると混乱し、AI利用コストもかかるので、部門ごとに展開範囲を検討すべき ©Mitsubishi Electric Corporation 13