これからSAMLをやる俺たちへ
IdP導入する前に、いろいろ忘れそうなのでSAML設定する時に必要だった、便利だった機能を独断と偏見で備忘録として残しておきます。
正直、IdPやSPごとにハマり所が違ったりして、IdPなら、Azure ADならうまくいくけどOktaでうまくいかんとか、まず特定のIdPにしか対応してないとか、SP(サービス)毎に実装方法の違いも当たり前にある世界なので、助けになるものが多ければ多いほどがいいし、実際導入した翌日に問い合わせの嵐に疲弊しないためにもいろんな状態で検証するのが吉ってことで、そんな時のために何を前の私が使ってたかを忘れる前にメモします。
とりあえずテストユーザーを作る
SSOの検証をする時は必ず設定は、管理者権限でやることになるのですが、サービスによっては、管理者はSSOが適用しない場合とかあるんですよね。
メジャーなサービスだとG Suiteとか、設定しても管理者はIDとPASSのままです。これは、万が一、IdP側が死んだ時にSSOの設定切るためとかそんないろいろ理由です。割愛
そんな感じなので、一般ユーザーという立ち位置のテストユーザーを作成します。ssotest@domainみたいな。
基本的にこのユーザーでテストをするというのを基本にするといい感じです。
ってここまで書いて思ったのが、基本的に一人でSSOの設定する前提でした。もしチームメンバーがいるなら、そのユーザーを一時的に一般ユーザーに落としてテストするのもいいかもしれないです。ただ、普段使いしてるユーザーに影響あるのもあれなので、ライセンス的な問題がなければテストでユーザーを作るのが望ましいんではないかと思います(個人的に)
あと、複数ロール(権限)がある場合はそれごとに作成テストユーザーは作成した方がいいです。
SAMLのレスポンスを視覚化できる拡張子や開発者コンソールを設定する
設定をしている時に、うまくいかねーぜって場合はAttributeや証明書などが、うまくIdPからSPに渡っているかどうかを確認する必要があります。
方法としては、SAMLレスポンスを確認する、IdPからSPにログインをしようとした時のIdP側の該当ユーザーのLogを確認することです。
後者に関しては、IdPごとにLogの画面や、どこまでLogを表示してくれるか変わるので、一概に言えないので利用するIdPごとに柔軟に対応して欲しいというところです。
まだ導入していない場合は、失敗した時や正しくユーザーがアクセスできていてもどのような状態でLogが確認できるかというのも評価対象に入れるといいかと思います。
前者に関しては解決方法が方法としては2つ
ブラウザに拡張を入れる
ChromeでもFirefoxでもSAMLのレスポンスが取れる拡張があります。
種類は多種多様で、SAMLのみを取得するタイプだったり、startボタン押してから終了のボタンを押すまでの通信を取得するタイプだったり。
おすすめというか、よく使ってたやつ
あともう一個のパターンの開発コンソールに表示させるやつとかもある。
いろいろ種類があるので好きなものを選んでみたりいっそ全部入れてみたりしてもいいと思います。
今回紹介したのは、ChromeのものですがFirefoxだったり他のブラウザでもSAMLレスポンスを確認できる拡張機能はあるのでいろいろ探してみてください。
各ブラウザの開発コンソールにSAMLのレスポンスを表示させる
開発コンソールにSAMLのレスポンスを表示が可能です(通常は非表示だったはず)なので表示させてそれで確認をするのもありです。
当たり前ですが、ブラウザごとに表示方法はAWSのドキュメントが一番網羅してるので、参照してください
トラブルシューティングのためにブラウザで SAML レスポンスを表示する方法
まぁ、SAMLのレスポンスみてもわからん！って場合でも、完全に設定で詰んでサポートに連絡をしようと思った時に、ここら辺の情報を記載してあげると、サポート側も返答しやすいというか、エラーコードすら出さずに失敗することも多々あるので、こういうレスポンス系はしっかりとって、質問しようね。なんならわかるようになったら自己解決できるねっていう
拡張入れるか、管理者コンソール設定するかは趣味なので、好きなの選べばいいと思います。便利な方で間違ってなければ、ヨシ！
コードエディタを入れる
なんでいきなりコードエディタ?となるかもしれませんが、割と頻繁に使います。あとSSO以外でも使えるので便利。そもそも入ってるケースの方が多いかな?
SSOの設定時で使うユースケースは、SPによってはIdPの証明書の中身をコピペするという方法をとる場合があります。そんな時に、使います。
ぶっちゃけ、標準メモでもいいっちゃいいんですが、変にスペースとか入るのと設定に失敗するので、エディタツールは入れておいた方がいいと思います。
VScodeとか。そこら辺のお好きな物をどうぞ。折り返し機能がついてればなんでもいいと思います。
SP側sandbox環境を作れる時はできるだけ作る
素振りは大切。この時に気にしておきたいのは、環境だけ持ってきてユーザー情報はsandbox環境に持ってきてないみたいなミスをすると気がつくまで、永遠にSSOできない。なぜならsandboxにユーザーがいないから
sandboxが作れるSPだと有名どころは、SFとかが作れますね。まず作れるかどうかを確認してみてください。
通常使わなくてもブラウザは複数利用する
いつだってChromeだぜー!っていうのが私ですが、設定する時のSSOの挙動確認ではFirefoxやIEなんかも使っていました。
理由としてはいくつかありますが、キャッシュが全くない環境でテストを行いたいとか、特定部門はこのブラウザが基本です。とか、そういうのに対応する為です。
シークレットブラウザでもいいじゃないかという考えもないわけではないんですが、複数ブラウザで挙動を確認しておいた方が、謎の心理的安心を得られたので、どちらかと言うとシークレットブラウザもやりつつ他ブラウザでもテストしてました。
キャッシュ削除の拡張子を入れる
上とほぼ似たような理由ですね。
うまくいったー!と思ったら、実はキャッシュが残ってたからうまく行ったと思った時もあった...が、あるあるネタなのでキャッシュ削除は大切。
設定から消すことができますが、いちいちそれをするのがめんどくさかったので、ワンぽちで削除できるキャッシュ削除の拡張子入れてました。
とりあえず、ここら辺でパッと思いついたのは以上になるので、ここから以下は超汎用版のなんか知らんがうまくいかない時のトラブルシュートというか、ハマりどころ一覧です
-------
IdP側とSP側で値のmappingが正しいか確認する
ID/PASSでログインしてた時は、メールとパスワードだけど、SSOの設定する場合のIDのメールじゃなくて違う値って時があります。SP側でそれをドキュメントにきちんと記載ところもあれば、サラッと終わらせる時もあるので、まぁ注意です。
そもそもSP側にユーザーがいるのか?あるいはその反対
テスト用でアカウント作るとよくやるのが、SP側にユーザーを作り忘れることです。プロビジョニングの設定も一緒にやってたら、問題ないですけど。
世の中そんなうまい話はないので、SSOの設定は大体夜間にやることが多いので眠い中やって犯す凡ミスです。
IdPからSPに遷移できるけど、SPに直接URLを叩くとエラーがでた。またはその逆
これは、SP-Initiatedと IdP-InitiatedというSAMLの挙動の違いです。大体のサービスがどっちにも対応してるので、まぁいけるやろって思うとたまにハマります。
SP-Initiatedと IdP-Initiatedについてはググれば詳細に記載したドキュメントがあるのでそっち読んでください。
簡単に説明すると
SP-Initiated -> サービスに直接アクセスをすると、IdPのログイン画面に遷移しIdPのログイン後サービスにアクセスができる(IdP側にキャッシュが残っている場合はログイン画面はスキップされます)
IdP-Initiated -> IdP側のアプリ一覧画面から該当のサービスにアクセスができる。(もちろんIdP側のアプリ一覧にアクセスするにはログインが必要)
IdPで割り当てたロールとSPで割り当てたロールがあってるか
これはユーザーに付けた権限のことです。サービスによっては複数の権限があるわけで、これはもちろんSSO時にはIdPとSP側で統一しないといけません。間違ってると、大体高確率でエラーになります。
ざっと思い出しただけで、これくらいはありました。人間ちょっとやらないだけですぐ忘れちゃうね。
きっともっとあるので、思い出したらその度に追記していきます。
お昼ご飯代で使います