●調査リスト
①公式サイト
https://aws.amazon.com/jp/single-sign-on/?c=sc&sec=srv
②ユーザーガイド
https://docs.aws.amazon.com/ja_jp/singlesignon/latest/userguide/what-is.html
③BlackBelt
https://www.slideshare.net/AmazonWebServicesJapan/20200722-aws-black-belt-online-seminar-aws
④DevelopersIO記事一覧
https://dev.classmethod.jp/tags/aws-sso/
⑤リリースノート
https://aws.amazon.com/jp/new/?whats-new-content-all.sort-by=item.additionalFields.postDateTime&whats-new-content-all.sort-order=desc&awsf.whats-new-security-id-compliance=general-products%23aws-single-sign-on
⑥ドキュメント更新履歴
https://docs.aws.amazon.com/singlesignon/latest/userguide/doc-history.html
●温度感調査
Developers IO パラメータ
記事数：8
最終更新日Top3：2021.01.25 → 2020.11.30 → 2020.11.24
サービスアップデート状況
サービス提供開始：2017/12/08
2020/12/15 AWS Single Sign-On で Microsoft Active Directory (AD) の同期をサポート
2020/10/07 AWS Single Sign-On で Ping Identity ユーザーの AWS へのアクセスを一元管理
2020/09/10 AWS Single Sign-On がアカウント割り当て API と AWS CloudFormation サポートを追加して、マルチアカウントアクセス管理を自動化
2020/09/02 AWS Single Sign-On がさらにアジアパシフィックの 3 つのリージョンで利用可能に
2020/07/31 AWS Single Sign-On で OneLogin ユーザーの AWS へのアクセスを一元管理
2020年内のサービスアップデートアナウンス：8
ドキュメントアップデート状況
https://docs.aws.amazon.com/singlesignon/latest/userguide/doc-history.html
December 21, 2020 Adjustments to quota tables.
December 21, 2020 Added new customer managed policy examples and updates to the permissions required section.
November 24, 2020 Added content for ABAC feature.
November 23, 2020 Updates to require users to enroll an MFA device at sign-in.
November 20, 2020 Added content for new WebAuthn feature.
2020年内ドキュメントアップデート回数： 8回
●AWS Single Sign-On サマリ
自社ならびに自組織内で、１人のユーザーが複数のAWSアカウントへのアクセスを行う必要があることを前提としている場合に、SSOを使うことで認証認可を一元化し、それぞれのアカウントにおける権限管理（正確にはIAMのフェデレーテッドロール）を透過的に行えるサービス。
そもそもこのサービスを理解するには、IDフェデレーションそのものの構造を理解しないといけないのだが、私個人としてもこのあたりに疎いため、そのおさらいから行った。IDフェデレーションの基本的な考え方については、BlackBeltの下記スライドがめちゃくちゃ分かりやすい。ようはパスポートのようなものだ、ととらえるとシーケンス含めて理解がしやすい。
またAWS SSOをサマる前に、IDフェデレーションの基本用語として下記に触れておきたい。私なりの言葉で書いているのでかなり拙いがご容赦いただきたい。（間違っている箇所があればぜひ指摘頂きたい）
アイデンティティストア
IDの「認証」情報を保有するDBを持っている場所のこと。実世界で言えば戸籍謄本や住民票のようなもの。
ID自身が実在していることを証明する。
IDプロバイダ
IDの「認可」情報を保持し、パスポートにあたる「アサーション」と呼ばれるものを発行する場所の事。上記の例でいえばパスポートを発行してくれるところなので、市役所を通して外務省が発行するイメージ。
その人（ID）がどの国（サービスプロバイダ）に対してどんなことができるか？という権限情報を管理している。
サービスプロバイダー
ログインしたいサイトやサービスを指す。実世界でいえば、行き先の国。AWSでいえば個々のAWSアカウント自身のことを指す。
AWS SSOは上記におけるIDストア＋IDプロバイダの機能を実装したマネージド・サービスであり、これらはレイヤー毎にサードパーティサービスや自前構築のものを組み合わせて利用することもできる。例えば、IDS: オンプレのAzureAD IDP：AWS SSOといった具合だ。（このあたりの選択のフローはBlackBeltで紹介されている。）
深くは触れないが、SAMLが喋れるIdPがあればそことの信頼関係を結ぶことでAWS SSOとまったく同じ機能を外側に実装することができる。
またAWS SSOでは、ログイン先の各AWSアカウントでどの権限を持つか？は、AWS SSOの中にできるSSOインスタンスという領域の中で、「アクセス権限セット（Permission Sets)」としてIAMポリシーを設定して管理し、接続先のアカウントと信頼関係を結んだ時点で、接続先のアカウント側に同じポリシーをもったIAMロール（フェデレーテッドロール）が作成される。実際のログインシーケンスでは当該アカウントにログインする際にこのIAMロールにスイッチロール（AssumeRole）することで権限が与えられる形となる。
このあたりを理解するのに、Developers IOの下記記事が非常に役に立った。私のようにIDフェデレーションへの知見が足りない人は是非一読されたい。
↓AWS SSOを図解してみた | Developers.IO
https://dev.classmethod.jp/articles/aws-sso-wakewakame/
深堀りの有無
実施しない
●所感
今回、IDフェデレーションの基礎的な理解からスタートしたので別の意味で勉強になりました。実際にAWS SSOを設計するときにはもっと深入りが必要だと思います。
AWSのマルチアカウント戦略としてAWS Organizationsを有効化することはデファクトであり、かつ環境毎あるいはサービス毎に複数のアカウントを発行することがベストプラクティスだと聞いています。だとすれば社内のAWSユーザーは担当するサービス x 環境ぶんのAWSアカウントを保有することになり、これを個別にID管理していくのはあまりにも非現実的だと思います。
上記のような運用をしている企業において、たとえば発行されたAWSアカウント上でのID管理（IAMユーザーとポリシーの運用）をユーザー部門（開発・運用担当部門）に委譲させていたとして、担当サービスが少数であるならまだしも両手で数えられないような数に増えてきたときには、AWS SSOが有効になっていないとユーザー部門でのID運用が煩雑になり、最悪ヒューマンエラーの温床となる可能性も出てきます。
弊社は諸事情によりAWS Organizationsが利用できないので、現時点でAWS SSOを活用することはできないのですが、上記を鑑みるとなる早でAWS Organizationsを有効化する必要があると思われます。すでに導入検討段階には入っているため、適用は加速したいところです。
●参考情報
↓[AWS Black Belt Online Seminar] AWSアカウント シングルサインオンの設計と運用 資料及び QA 公開 | Amazon Web Services ブログ
https://aws.amazon.com/jp/blogs/news/webinar-bb-awsaccountsso-2020/
