AWS SSOなどを使いマネジメントコンソールや外部Webサービスをシングルサインオン化する（各種サービス設定）

はじめに

この記事は以下の記事の続きとなります。
https://qiita.com/morin_river/items/0a36fd5c02976f6cb774

が、ここではSAML 2.0の認証方法を書いているので
AWS SSO以外のSAML 2.0認証アプリケーションの参考になるでしょう。

補足

SAML 2.0規格のサービスであれば
One LoginやGoogle SSOなどでも同じように使えると思います。
現時点ではOne Loginがサービスとしては一番使い勝手が良さそうです。
ユーザ数などで私は要件に会いませんでしたが
SSOサービスはAWS SSO以外も含めて検討するとよいでしょう。

共通の内容

用語

今回は、AWS SSOを利用するために最小限の説明になります。
そのため、正確には間違っている可能性はあります。
SAML 2.0の詳細は奥深いので、調べて見てみるのも面白いでしょう。

SP

Service Providerの略です。
SAML 2.0によって認証されるサービスを指します。
ここでは、RedashやJenkinsなどになります。

IdP

Identity Providerの略です。
IDの正当性を評価するものを指します。
ここでは、AWS SSOとなります。

SPとIdPに関してはこちらのページに詳しくあるので、参照してください。
http://nantonaku-shiawase.hatenablog.com/entry/2016/07/13/081053

ACS

AssertionConsumerServiceの略です。
SAML 2.0のセッションを確立するために使われます。
SAML 2.0アプリケーション上から提供されるURLを使うことが多いようです。

正確には、以下のページを参照してください。
https://wiki.shibboleth.net/confluence/display/CONCEPT/AssertionConsumerService

Audience

SAML 2.0アプリケーションの要素を検証するのに利用される値です。
通常はSPで設定するEntityIDかACSのURLになります。
正確には、以下のページを参照してください。
https://support.okta.com/help/Documentation/Knowledge_Article/Common-SAML-Terms

手順

Active Directoryの属性マッピング情報を入力

ダッシュボードから「Connected Directory」を選択し、「Attribute mappings」を表示します。
ここでは、Active DirectoryからSAML 2.0アプリケーションに渡す属性をマッピングします。

そこで、「Edit attribute mappings」ボタンから
「Active Directory」と「AWS SSO」のマッピング設定が行えます。

ただ、この属性マッピングには罠があり、Active Directoryのデータをすべて使える訳ではありません。
Active Directoryでは多くの属性を定義できるのですが、
AWS SSOで利用できるActive Directoryの属性は以下の限りとなります。
https://docs.aws.amazon.com/ja_jp/singlesignon/latest/userguide/attributemappingsconcept.html

以下引用です。

Supported Directory Attributes

Supported attributes in your connected directory
${dir:email}
${dir:displayname}
${dir:distinguishedName}
${dir:firstname}
${dir:guid}
${dir:initials}
${dir:lastname}
${dir:proxyAddresses}
${dir:proxyAddresses:smtp}
${dir:proxyAddresses:SMTP}
${dir:windowsUpn}

ここに記載されいる属性のみがサポートされている属性となります。

そして、このパラメータがすべて使える訳ではありません。
AWS SSOに繋ぎこむときは、以下のパラメータのいずれかマッピングする必要があります。

Supported AWS SSO Attributes

Supported attributes in AWS SSO
${user:AD_GUID}
${user:email}
${user:familyName}
${user:firstName}
${user:middleName}
${user:name}
${user:preferredUsername}
${user:subject}

少ない…せめてpositionとかの属性は欲しい…。
この通り、AWS SSOではグループに相当するパラメータがありません。
Redashなどユーザごとでグルーピングされたパラメータが欲しかったので、苦し紛れに私はActive Direcoryのemailの値にグループ属性をもたせました。
これは余り良い方法じゃありません。
SSOのパスワード再発行機能が利用できない可能性があります。

私は要件としてパスワード再発行を利用しなかったのでこの運用で問題なかったのですが、
ここは早くアップデート来て欲しいな…。

新規AWS SSOのアプリケーションの追加

ダッシュボード上から「Applications」を選択し、「Add a new application」ボタンで
新規にアプリケーションを追加します。

一覧に追加したいSAML 2.0アプリケーションがない場合
「Custom SAML 2.0 application」を選択してください。
2018年6月時点ではそこまで初期設定済みのアプリケーションが多い訳ではありません。
（今回の記事内のアプリケーションで記載があるのはG Suiteのみです）

基本パラメータ入力

設定の入力画面はこのような画面になります。

以下のようにAWS SSOの設定にSPのパラメータを入力します。

項目	内容	サンプル
Display name	SSOポータル上の表示名を入力します	SAMPLE APP
Description	説明を入力します。（恐らく）マネジメントコンソールでのみ参照します	sample application.

これ以降は、アプリケーションごとに個別となります。

アサインするユーザの入力

作成したアプリケーションにアサインさせるユーザを指定します。

ダッシュボードから、「Applications」「Assigned users」と遷移します。

「Assign user」ボタンを押し追加するユーザを選択します。

ここでは、Active Direcoryのユーザ単位ではなくグループ単位でも指定できます。
マッチするユーザ/グループ名を入力し、「Search Connection direcory」ボタンを入力し検索します。
その結果から追加対象を選択し、「Assign users」ボタンでアサインを完了します。

一度GUI上で設定が完了すれば、次回移行はAD上のグループにユーザを追加するだけでユーザ登録ができますね。
私はADのユーザ登録はAnsible化しているので、
初期設定さえ完了すればCUIのみの作業で完結するようにしています。

この記事でグループ所属にこだわっていたのはこのような理由があるからでした。
ここで登録すれば、AWS SSOのユーザポータル画面に追加したアプリケーションが表示されます。

もちろん、実際にSSOが使えるのはアプリケーション固有の設定が終わってからですが
なれないうちは切り分けの為にここで確認するのも良いでしょう。

Redashへの導入

前提

Redashのv0.11以上が必要です。
現行バージョンでは既存のユーザは維持されますが
後方互換性が維持されるかどうかは不明です。

また、v4.00からGUIの画面でSAML 2.0の設定ができるようになりました。
https://redash.io/help/user-guide/users/authentication-options

そうかー…一時期ドキュメントがなかったのはこの切り替え時期だったから…大変だったのに
v4.00より上のバージョンの場合、.envファイルに記載する手順をGUI操作に置き換えても良いかもしれません。

また、RedashでSAML 2.0が使えるようになるには
Cybozuのエンジニアの方の大きな貢献があったようです。
http://blog.cybozu.io/entry/2016/12/19/080000

感謝しながら使わせて頂くようにしましょう。

手順

他のアプリケーションと同じく共通手順からカスタムアプリケーションを作成しておきます。

アプリケーションパラメータ切り替え

Application metadataを設定します。
Redashでは、2018年6月現在metadataファイルはありません。
そこで手動でmetadataの値を入力します。

以下の画面から、切り替えボタンを押します。
わかりにくい…。

そうすると、画面がこのように切り替わります。

アプリケーションパラメータ入力

出てきた入力欄に、以下のように入力します。

項目	内容	サンプル
Application ACS URL	Redashでは、自ホストの末尾に/saml/callbackをつけたものをACSのエンドポイントとするようです。	https://redash.example.com/saml/callback
Application SAML audience	ここでは、Application ACS URLと同じにします。	https://redash.example.com/saml/callback
Application start URL	Redashでは、自ホストの末尾に/saml/loginをつけたものをSAMLアプリケーションのログインエンドポイントとするようです。	https://redash.example.com/saml/login

ここで設定する値は、特にドキュメントに乗っておらずソースから探して設定したので
将来変更される可能性はあります。
ですが、ホスティングRedashのドキュメントに似た値を設定する手順が追加されていたので大丈夫かな…。

属性のマッピング情報を入力

Redash固有のマッピング情報を入力します。

項目	内容	フォーマット	サンプル
Subject	WindowsUPNが設定されるsubjectを入力します。	transient	subject
FirstName	ユーザのFirstNameを入力します。AWS SSO上ではgivenNameに相当します。	nonescaped	${user:givenName}
LastName	ユーザのLastNameを入力します。AWS SSO上ではfamilyNameに相当します。	nonescaped	${user:familyName}
RedashGroups	ユーザの所属するRedash上のグループを指定します。私は、共通項目のマッピング項目に記載している通り、ADのemailにグルーピング情報を入力しています。	nonescaped	${user:email}

アサインするユーザ情報を入力

共通の「アサインするユーザの入力」欄を参照してください。

Redash上の設定

AWS SSOの「configuration」タブからAWS SSOのmetadataが記載されているURLを取得します。
このURLはアプリケーションごとに新しいものが発行されます。

通常の画面からはなぜかダウンロードボタンしか表示されません。
が、「Edit Configuration」ボタンを押すことでmetadata fileのURLがコピーできようになります。
まぁ、Redashではローカルのmetadata fileを指定できるので
ダウンロードしたものをサーバに配ってもよいでしょう。

Redash上で設定が記載される「.env」ファイルに以下の項目を追加します。
上記の通りRedash v4.0以上のバージョンでは設定画面に同じ項目があるようです。
（私は未検証です）

export REDASH_SAML_METADATA_URL="YOUR_AWS_SSO_METADATA_URL"
export REDASH_SAML_ENTITY_ID="YOUR_REDASH_APPLICAITON_ENTITY_ID"

# example

export REDASH_SAML_METADATA_URL="https://portal.sso.us-east-1.amazonaws.com/saml/metadata/XXXXXXXXXXXXXXXXXXXXXXXXXXXX"
export REDASH_SAML_ENTITY_ID="https://redash.example.com/"

REDASH_SAML_ENTITY_IDは、本来ならSAML audienceとあわせて末尾に/saml/callbackを加えた方が良いかもしれません。
上記設定を記載したあと、Redashプロセスを再起動します。

そうすると、通常のRedash設定画面の上に「SAML Login」という項目が現れます。

ここで、AWS SSOにログインしているとSAML 2.0の認証を使いRedashにログインが可能です。
また、AWS SSOのユーザポータル上のアイコンをクリックすることでもログインができるようになります。

この時、すでに既存のユーザでRedashにログインした状態だと既存ユーザのログインセッションを使ってログインします。
必ずログアウトし、別ユーザでログインできているか確認しましょう。
成功していれば、AWS SSO用のユーザが作成されています。

G Suiteへの導入

前提

G SuiteへSSOを導入することで
GCPなどのサービスも同じようにSSOで管理することができます。

G Suiteへの導入は、いくつか注意しておくべき点があります。
サービスのSSO化はしますがG Suiteだけ要件に合わないから
以前の運用のままにしておくというのもひとつの方法かもしれません。

他のGoogleサービスを利用している場合の問題

GoogleのサービスはGoogleアカウントに紐付かれます。
また、SAML 2.0のログインを有効にすると、
全てのユーザでSAML 2.0を要求されるようになります。
そして、恐らくGoogleアカウントはサービス利用時にユーザ認証が行われます。
つまりID + パスワードの認証ができなくなります。

その結果、導入しようとしているG Suiteにログインしているクライアント（ブラウザなど）では
SSOの認証が終わるまで他のアカウントのGoogleサービスも利用できなくなります。

組織のGoogleアカウントのSSOアカウントが発行しおわるまで
個人で利用しているGoogleドライブが使えない、みたいなことが発生します。
導入が終わると大変便利に使えるのですが
切り替えまでの周知や確認はしっかり行っておくといいでしょう。

GoogleによるSSOの公式リファレンスは以下となります。
https://support.google.com/a/answer/60224?hl=ja

ユーザアカウントの問題

G Suiteアカウントは、SSOから作成する事はできません。
アカウントごとに課金されるので仕方ないのですが
他のSSOアプリケーションはアカウントが無い場合作成する挙動をすることが多いので
注意が必要です。

AD上のユーザのメールアドレスの問題

AWS SSOからG Suiteに渡されるE mailパラメータと
G Suite上のアカウントで登録されているアカウント名が一致している必要があります。
これだけであれば特に問題はないのですが
SSOに登録できるパラメータが少ない点を考えると悩ましい事になります。
私はRedash上のグループパラメータとしてE mailパラメータを利用する必要があったため
G Suite用にパラメータを1つあけることができませんでした。

そのため、ADのdisplay name欄をG Suiteのアカウント部分と一致させて
演算子でドメインを追加するという強引な方法を取っています。

ADのパラメータを自由に設定できる場合でも考える必要があるため
既存のADにつないでSSO管理する場合はパラメータを前もって考えておきましょう。

手順

他のアプリケーションと同じように、Applicationを作成しておきます。
Applicationの種類は「Custom SAML 2.0 application」ではなく「G Suite」を選択します。

G SuiteのSSO設定

上記手順にしたがって設定を行います。

[セキュリティ] > [シングル サインオン（SSO）の設定] をクリックします。

[サードパーティの ID プロバイダで SSO を設定する] チェックボックスをオンにします。

サードパーティの ID プロバイダ（IdP）に対して次の URL を入力します。

AWS SSOコンソールの「AWS SSO metadata」欄から以下のように入力します。

G Suite上の項目	AWS SSO metadata上の項目
ログイン ページの URL	AWS SSO sign-in URL
ログアウト ページ URL	AWS SSO sign-out URL
パスワード変更 URL	以下に記載
認証の確認	AWS SSO certificate から証明書をダウンロードし、G Suiteにアップロード
ドメイン固有の発行元を使用	必要なら入力してください（未検証）
ネットワーク マスク	必要なら入力してください（未検証）

パスワード変更 URLに関しては、不明です。
パラメータから類推すると「AWS SSO issuer URL」が該当しそうですが、G Suite上のドキュメントには言及がありません。
そして、後述するAWS SSOのG Suiteドキュメント上にも言及がありません。
実際の入力欄には記載があります。
挙動も確認できていないので、私は未入力にしています。
（こちら、ご存知の方がいればお教えください）

AWS SSO上のG Suiteの設定

AWS SSOのG Suiteアプリケーション「Configure」タブ上の「Edit Configure」ボタンを押します。
ここで、「Configure G Suite」ページの上部にG Suite用のドキュメントが出てきます。
何故かURLにアプリケーションのIDが入っているので
こちらにはリンクを張りません。

以下、ドキュメントに従い設定を行います。

アプリケーションパラメータ入力

「Application metadata」欄まで移動します。

「If you don't have a metadata file, you can manually type your metadata values.」ボタンを押し
手動設定に切り替えます。

出てくる入力欄に以下のように値を入れます。

タイトル	値	サンプル
Application ACS URL	https://www.google.com/a/ + G Suiteで運用しているドメイン + /acs	https://www.google.com/a/example.jp/acs
Application SAML audience	google.com/a/ + G Suiteで運用しているドメイン	google.com/a/example.jp
Application Start URL	https:// + ( mail or drive ) + .google.com/a/ + G Suiteで運用しているドメイン	https://drive.google.com/a/example.jp

G Suiteのドメインですが、ドキュメント上では**.com**という記載だっために
「example.jp.com」みたいな入力ルールの必要があるのかと試したのですがドキュメントの記載が違うようです。
通常運用しているG Suiteのドメインで良いでしょう。

また、Start URLはG MailかG Driveしか選択できません。
GCPダッシュボードやBigQueryが入力できたら便利だったのですが…。

ユーザポータルを介せず認証のみで使う場合には問題はないのですが
このあたりはアップデートでの対応待ちとなります。

属性のマッピング情報を入力

注意点でも書いてますが、G Suiteへは登録済みのG Suiteのアカウント名を渡す必要があります。
最初から入力されてはいますが、SubjectとEmailパラメータにG Suiteのアカウント名を渡せるようにしておきましょう。

上記のようにパラメータと文字列をつなげることは可能です。
実際にどのようなパラメータが渡されるか確認したい場合は
ユーザポータルからShiftを押しながらアプリケーションを選択してデバッグすることも可能です。

アサインするユーザ情報を入力

共通の「アサインするユーザの入力」欄を参照してください。

他のアプリケーションと同じです。
共通の欄を参照してください。

Jenkinsへの導入

前提

JenkinsにSSOを導入することで、Jenkinsの管理を容易にすることができます。
特にJenkinsサーバが大量にある場合
ユーザポータルでまとめて管理することができるので
使い勝手がぐっと上がるでしょう。

JenkinsのSSO化にも注意があります。
SSO化すると、既存のユーザは利用できなくなり
SSO認証されたユーザのみが許可されます。

ユーザでの利用だけならいいのですが、
Jenkinsのコールを別システムなどから呼んでいる場合は注意が必要です。

手順

他のアプリケーションと同じく共通手順からカスタムアプリケーションを作成しておきます。

JenkinsのSAMLプラグインを導入

https://plugins.jenkins.io/saml
このプラグインをJenkinsに導入します。
Ansibleなどで導入するのがスマートですが
ここではGUIから設定する方法を記載します。

「Jenkinsの管理」から「プラグインの管理」に進み「利用可能」タブをクリックします。

フィルターに「saml」と入力するとSAMLのプラグインが出てきます。
ここで、バージョンのアラートが表示される事があります。
要件にあうかは確認しておいた方がよいでしょう。

大丈夫なら、インストールします。
私の環境では再起動は不要でした。

Jenkinsのセキュリティオプション変更

同じく「Jenkinsの設定」から「グローバルセキュリティの設定」を選択します。

「アクセス制御」から「ユーザー情報」を「SAML 2.0」に変更します。
この変更完了後、今までのユーザID・パスワードは利用できなくなるので注意してください。

以下、パラメータを入力します。

項目	説明	サンプル
IdP Metadata	IdP(AWS SSO)のMetadataを入力します。AWS SSOのアプリケーションの設定から「AWS SSO SAML metadata file」をダウンロードし、貼り付けます。	<?xml version ...
IdP Metadata URL	IdP(AWS SSO)のMetadata URLを入力します。AWS SSOのアプリケーションの設定から「AWS SSO SAML metadata file」のURLをコピーし貼り付けます。上記どちらかで良いかもしれません。	https://portal.sso.us-east-1.amazonaws.com/...
Refresh Period	IdPのMetadata更新間隔です。0だと更新しないようです。	0
Display Name Attribute	Jenkinsのユーザ表示名に使われるSSOの属性です。	preferredUsername
Group Attribute	Jenkinsのユーザが所属するグループに使われるSSOの属性です。上記注意項目にあるように、emailを利用しています。	email
Maximum Authentication Lifetime	userの認証保持期限だと思われます。初期値で運用しています。	86400
Username Attribute	Jenkinsのユーザ名に使われるSSOの属性です。	preferredUsername
Email Attribute	userのemailに利用するSSOの属性です。	email
Username Case Conversion	Usernameを大文字小文字変換するかどうかです。	None
Data Binding Method	DataのBinding方法が選べるようです。AWS SSOの場合は標準の「HTTP-Redirect」で問題ありませんでした。	HTTP-Redirect
Logout URL	IdP(AWS SSO)のsign-out URLを入力します。AWS SSOのアプリケーションの設定から「SSO sign-out URL」をコピーし入力します。	https://portal.sso.us-east-1.amazonaws.com/...

入力が終わったら左下の「保存」ボタンを入力します。
また、この画面の中にSPのmetadataがダウンロードできる項目があります。

ここからSP metadataをダウンロードし保存しておきます。

アプリケーションパラメータ切り替え

AWS SSOのJenkinsアプリケーション「Configure」タブ上の「Edit Configure」ボタンを押します。
「Application metadata」欄まで移動します。

「Application SAML metadata file」に先ほどダウンロードしたSP metadataをアップロードします。
「Application start URL」欄にはJenkinsのエンドポイントを入力します。

属性のマッピング情報を入力

マッピング情報を入力します。

項目	内容	サンプル	フォーマット
Subject	WindowsUPNが設定されるsubjectを入力します。	${user:subject}	unspecified

特に設定が不要に見えるのですが
初期設定のままSubjectの値が空白だと「Something went wrong and we could not sign you in ${APPLICATION NAME}」というエラーが出ます。
このエラーは直感的にわかりにくいのですが、マッピングがきちんと入力されているか確認しましょう。

アサインするユーザ情報を入力

共通の「アサインするユーザの入力」欄を参照してください。

Wordpressへの導入

前提

WordpressへのSSL認証は「OneLogin SAML SSO」プラグインを利用します。
このプラグインはOneLoginで使うために作られているのですが
SAML 2.0準拠のプラグインの中では一番しっかりと作られていそうです。

https://github.com/onelogin/wordpress-saml/blob/master/LICENSE
MITライセンスで作られているので、
ここではWordpressをSAML 2.0準拠のIdPに導入するという体で紹介します。

SAML 2.0を強制するかどうか、細かい権限設定など細かく設定できるので
他のサービスに比べSSO化のハードルは低そうです。

手順

Wordpressプラグインを導入

https://github.com/onelogin/wordpress-saml/releases
ここから、リリースのプラグインのzipをダウンロードします。
そして、Wordpressのプラグインのフォルダに展開します。

$ ls -la /your/dir/wp-root/wp-content/plugins/onelogin-saml-sso/
total 48
drwxr-xr-x 4 user group 4096 Jun  1 00:00 .
drwxrwxr-x 9 user group 4096 Jun  1 00:00 ..
-rw-r--r-- 1 user group  219 Jun  1 00:00 alternative_acs.php
-rwxr-xr-x 1 user group 1554 Jun  1 00:00 icon.png
drwxr-xr-x 4 user group 4096 Jun  1 00:00 lang
-rw-r--r-- 1 user group 7260 Jun  1 00:00 onelogin.png
-rwxr-xr-x 1 user group 4083 Jun  1 00:00 onelogin_saml.php
drwxr-xr-x 5 user group 4096 Jun  1 00:00 php
-rwxr-xr-x 1 user group 5454 Jun  1 00:00 readme.txt
-rw-r--r-- 1 user group  249 Jun  1 00:00 version.json

Wordpressプラグインを設定

Wordpressの管理画面に入ります（一般的にはWordpressのエンドポイント＋wp-adminをつけたURLです）。
「設定」項目から「SSL/SAML Settings」項目を選択します。

以下の項目を設定します。

項目	説明	サンプル
Enable	チェックをつけるとSAML 2.0が有効になります。
IdP Entity Id	issuer URLを入力します	https://portal.sso.us-east-1.amazonaws.com/...
Single Sign On Service Url	sign-out URLを入力します	https://portal.sso.us-east-1.amazonaws.com/...
Single Log Out Service Url	私はsign-out URLと同じ値を入力しました。	https://portal.sso.us-east-1.amazonaws.com/...
X.509 Certificate	IdPの証明書を入力します。AWS SSOの場合はダッシュボードからダウンロードしたものを貼り付けます。	-----BEGIN CERTIFICATE-----\n...
Create user if not exists	ユーザが存在しない場合、新規ユーザを作成します。
Update user data	IdPから送信された情報を元にユーザデータを更新するかどうかを設定します。
Force SAML login	SAML loginを強制するか選択します。チェックが外れている場合、既存のid/passwordでもログインできます。
Single Log Out	ログアウト時にSSOポータルに移動するか選択します。チェックが外れている場合通常のログイン画面に遷移します。
Keep Local login	通常のログインフォームを維持するか選択します。チェックを入れている場合、通常のログインフォームにSAMLログインが追加されます。
Alternative ACS Endpoint	別のログイン認証を有効にするときに必要なオプションのようです（未検証）
Match Wordpress account by	Wordpressのアカウントをどの属性でマッチさせるか選びます。「Username」と「Email」から選択できるようです。	Username
ATTRIBUTE MAPPING	SSOから渡された属性をどのパラメータにマッピングするか指定できます。	Username -> username E-mail -> email Role -> email
ROLE MAPPING	Roleが設定されているユーザをどの権限にするか設定できます。	このサンプルではEmailがRoleになります。Administrator -> infra-group
Multiple role values in one saml attribute value	権限を複数のロールベースにすることができるようです。（未検証）
Regular expression for multiple role values	Multiple role values in one saml attribute valueを正規表現で表現できるようです。（未検証）

以下細かい設定ができます。
要件に合わせて適宜必要なものを選択してください。

IdP（AWS SSOなど）にmetadataを設定する。

WP上のSAMLプラグインの設定の上部から、SPのmetadataをダウンロードできるようになっています。

これをIdPの設定画面に入力します。
AWS SSOの場合は、上部Jenkinsの設定を参照してください。

「Application start URL」に関してはWordpressの管理画面のURLを入力してください。

属性のマッピング情報を入力

マッピング情報を入力します。
One login Pluginの場合はWP上でもマッピングが設定できるので
ある程度柔軟に設定が可能です。

項目	内容	サンプル	フォーマット
Subject	WindowsUPNが設定されるsubjectを入力します。	${user:subject}	unspecified
username	WPのアカウントにあたる名前です。	${user:subject}	unspecified

アサインするユーザ情報を入力

共通の「アサインするユーザの入力」欄を参照してください。

さいごに

このように、SAML 2.0は各サービスごとに独自の実装や設定があるので
直感的には分かりづらいところもあります。
が、一度設定さえしてしまえばアカウントの運用がすごく楽になります。
みなさんも、ぜひSSO生活を！

AWS SSOのAD connection mapping、サポートするパラメータだけは増やしてほしいなぁ…。