AWS Single Sign-On(AWS SSO)で3rdParty Identity Providerが使えるようになったので試してみた

何が嬉しいわけ??

元記事はこちらです。
feedproxy.google.com

ざっくりいうと、
AWS SSOの認証元として、3rdPartyのSSO製品でユーザ認証ができるようになった
というやつです。

今までは、下記方法によりAWS SSOのユーザ認証が可能でしたがそれぞれ頭を悩ますデメリットがありました。

  • AWS Directory Serviceでユーザ認証
    • デメリット:既に既存のADサーバで運用している場合、統合ができないのでこちらの方式が使用できない
  • AD Connectorで既存ADサーバ情報をAWS上に同期する
    • デメリット:既存ADサーバとVPN接続等で接続するなど何かしら頑張らなければいけない。その後AD Connectorによる接続も必要。
      • AD環境のネットワークアドレスと、VPC上のサブネットが重複していたりするとネットワーク再設計が必要だったり...も。

また、上記デメリットがあるゆえに、IAMでIdentity Providerを登録して運用している人も多いと思います。(私もそうでした)
ただ、これにもデメリットがあり

  • AWSをマルチアカウント運用している場合、それぞれのAWSアカウントでIdentity Provider設定が必要

というなかなか辛い状況もあります。(幸い、Terraform化できるのでコード化できてればそこまで苦労はないといえば無いですが面倒は面倒)

それが、今回のリリースにより 3rdPartyのIdentity Providerが使用できることによりAWS Directory ServiceもAD Connectorも必要なくなったので上記デメリットが払拭された形になります。

また、上記デメリットが払拭されるばかりか、メリットとして

  • SSO後の画面で一時的なAWS CLIクレデンシャルが発行できる

というメリットもあります。(これが地味にすごく便利!!!) 今までは こういった ツールに頼らざるを得なかったので、今回のリリースはもうメリットしかないわけです。
(厳密にいうと、少しだけデメリットはありますが)

というわけで今後、AWS環境とSSOを結ぶ際には今回の方式がデファクトスタンダードになると思われますので、設定してみます。

設定編

基本的には下記記事を実行しているだけなのですが、元記事では手順がざっくりしている箇所もあるのでステップバイステップで少し詳細に書いていきます。 feedproxy.google.com

設定編:前提

前提として、下記準備が必要です。

  1. 対象AWSアカウントのrootアカウントでログインできること。
    • AWS Orgnizationの機能を使っている場合は親AWSアカウントのrootアカウントが必要です。
  2. IdPを用意済であること(今回はAzureADで実装します)

設定編:実装

それでは、上記記事を参考に実装していきます。

  1. Azureにログインし「Azure Active Directory」-「エンタープライズ アプリケーション - すべてのアプリケーション」-「新しいアプリケーション」と選択します。URLでいうと これ です。
  2. 「ギャラリー以外のアプリケーション」を選択します。
  3. f:id:undersooon:20191202010536p:plain
  4. 名前はなんでもいいのですが、わかりやすく「AWS」としておきます。
    • f:id:undersooon:20191202010645p:plain
  5. 作成した設定値に対してシングルサインオンさせたいユーザを選択しておきます。
  6. f:id:undersooon:20191202013713p:plain
  7. シングルサインオン」を選択し、シングルサインオン方式として「SAML」を選択します。
    • f:id:undersooon:20191202010758p:plain
    • f:id:undersooon:20191202010825p:plain
  8. 中腹あたりにある「③SAML名証明書」のメニューの中から「フェデレーションメタデータXML」を選択してダウンロードしておきます。
    • f:id:undersooon:20191202011043p:plain
  9. シングルサインオンしたいAWSアカウントにログインします。
  10. シングルサインオンコンソール( これ ) を開きます。
    • 東京リージョンでは使えない、みたいなエラーが出たりしますがリージョンは特段どこでもいいのでバージニア北部(us-east-1) あたりを選んでおきます。
  11. 「設定」を選びます。
    • f:id:undersooon:20191202011813p:plain
  12. 「IDソース」から「変更」を選びます。
    • f:id:undersooon:20191202011902p:plain
  13. メタデータファイルのダウンロード」をしておく。
    • f:id:undersooon:20191202012335p:plain
  14. AzureADに戻り「メタデータファイルをアップロード」で上記メタデータをアップロードする。
    • f:id:undersooon:20191202013905p:plain
  15. 再びAWSコンソールに戻り、「外部IDプロバイダー」を選択し、先程AzureADからダウンロードしたメタデータXMLをアップロードし、「次:確認」を選択します。
    • f:id:undersooon:20191202012025p:plain
    • f:id:undersooon:20191202012424p:plain
  16. 画面上に指示に従い、更新。
    • f:id:undersooon:20191202012621p:plain
  17. 設定が終わると、「Return to Setting」というボタンがでるので押す。すると一画面前に戻るので「キャンセル」と押してシングルサインオンコンソールに戻る。(ここはUIがよくないですね...)
    • f:id:undersooon:20191202012713p:plain
  18. ここまでで、SSO設定は終わりだが、ユーザプロビジョニング/グループプロビジョニングができないと旨味が全くないのでプロビジョニング設定する。
  19. 「自動プロビジョニングを有効化」を選択する。
    • f:id:undersooon:20191202013025p:plain
  20. 下記のようにSCIMエンドポイントとアクセストークンが表示されるのでメモしておく。
    • ※アクセストークンは一回しか表示されないので必ず値を控えておくこと。
    • f:id:undersooon:20191202013149p:plain
  21. AzureADに戻り「プロビジョニング」を選択して、上記SCIMエンドポイントとアクセストークンを入力し、「テスト接続」をしてみて成功することを確認する。
    • f:id:undersooon:20191202013437p:plain
  22. マッピング」-「Synchronize Azure Active Directory Users to customappsso」を選択する。
    • f:id:undersooon:20191202014108p:plain
  23. 「mail nickname」となっているところを「object ID」に変更して「保存」する。
    • f:id:undersooon:20191202014238p:plain
    • f:id:undersooon:20191202014331p:plain
  24. デフォルトではプロビジョニング周期は40分だが、さっさとテストしたいので下記のようにして「保存」を選択してすぐにプロビジョニングを走らせる。
    • f:id:undersooon:20191202014500p:plain
  25. AWS SSOコンソールに戻り、「ユーザー」欄にプロビジョニングされていれば成功!
    • f:id:undersooon:20191202014625p:plain

運用編

  • AWS アカウント」からSSOさせたいAWSアカウントを選択して、上記プロビジョニング済ユーザを割り当てればOK。(画面の指示に従えば簡単に設定できるので詳細は割愛)
    • f:id:undersooon:20191202014815p:plain
  • (AWS SSOの機能で元々できていたことではありますが)SSO済のポータル(シングルサインオンコンソールにURLが書いてあります)にログインして、「command line or programmatic access」を選択するとAWS CLI用の一時クレデンシャルが取得できます。(Winodowsの場合のものも用意されていて地味にうれしいですね)
    • f:id:undersooon:20191202015141p:plain
    • f:id:undersooon:20191202015102p:plain
    • f:id:undersooon:20191202015437p:plain

最後に

設定自体はとても簡単で、導入後の運用も煩雑なところがなくデメリットが特にないように思えます。 今まで、最初に述べたデメリットのせいでAWS SSOが導入できていなかった方はこの機会に是非導入することをおすすめします。 快適ですよ。