SalesforceのSAML認証で早とちりしつつも得られた事が多かった話
Okta Advent Calendar 2021の23日目、初のAdvent Calendarへ投稿します。
今年の秋頃からOktaを触りはじめました。
これまではSSOなんて設定手順があればそれに従って設定するもの、一度設定したSSOはリファクタリングをすることもなく、まさに一夜の関係で終わる作業と思ってました。
この3ヶ月、設定手順がなく色々なサイトや有識者の方のアドバイスを参考に触っていった結果、今年最後のSalesforceのSAML認証設定で色々得られたことが多かったので今回それをnoteにしました。
ちなみにSalesforceとOktaをSAML認証させる手順書ではないのでご注意ください。
はじめに
2021/12/11に発表されたPRで来年2月1日からSalesforceがMFAの必須化を明記した規約に変わります。
当初のPRはこちらでした。
これを見たとき来年2月1日までにMFAもしくはSSOの設定が必須だと勘違いしていました。
SSO云々はこのページを見てMFAを有効にしたSSOでなければいけない、つまりMFAを有効にしている会社のOktaでSalesforceとSAML認証しちゃえば解決するのではないかと思いました。
でも1つの疑問が生まれました。
OktaはMFAの有無をSalesforceに通知しているの？
その点を中心に今回得られたことをまとめてみました。
得られたこと
1.SAML Tracerを使う重要性を再確認したこと
OktaがSalesforceに通知を送る手段はマル5とマル6のSAML Responseの部分しかないためこのログを確認する手段として・・・
ブラウザを使ってSAMLのトレースを行えるSAML Tracerアドオンを使い、Responseの中身を見れば何の情報を送信しているか分かります。その結果MFAに関する情報は送っていないように見えます。
うまく連携できない場合、まずはSAML Tracerを使う（ログを見る）習慣がついてきたのが進歩したのか、と思いました。
2.仮説と検証から詳しい状況を知る意識が持てたこと
SalesforceのMFAの有無はSalesforceアカウント内の項目でチェックできるでしょう、多分。
仮にこれがSSO必須化が条件だとしたら何を以ってチェックしているのか気になってきました。この箇所だけで良いのか。
今回Sandboxを使って環境を作り、IdP Initiated SSOの設定をするとSalesforceの環境によってはSSOアクセスだけでなく、既存のパスワード認証でのアクセスも可能な状態だったことが分かりました。
公式ページを参考に、このような設定を施すとパスワード認証をブロックさせることができました。
SSO必須化の話しは想像で仮説に過ぎませんが、その仮説を立てることで仕組みや現状の状況を知ることができるようになりました。慣れると仮説を省略して検証だけで済ませがちですが、仮説と検証はセットで考えていくべきだと改めて思いました。
3.その結果リスクを把握することができたこと
SSOでもパスワード認証でも、アクセスできる状況だと判明しました。
SSOオンリーにしたらセキュリティ対策もバッチリ、万事解決かと思います。
ただ、Salesforceは様々なサービスと連携できます。大抵はAPI連携かと思います。
もし、連携先サービス画面でSalesforceアカウントを使ってログインしなければいけない場合、連携先サービスがSSOの挙動に対応しているのか、非対応だと使えなくなるもののそもそも業務上利用しているサービスなのか、などという疑問が生まれます。
私も思い立ったら、で進めてしまうことがあります。
今回の流れをきっかけに色々と仮説や検証を繰り返すことで何もかもスピーディーにクリアすることが最善ではないことを改めて発見しました。
急いで事をなすだけでなくブレーキをかけて検討する重要性を改めて気づきました。
4.ドキュメントの補足情報の重要さを改めて知ることができたこと
こちらはOktaが発表しているSalesforceのSAML認証設定の手順です。
この
How to Configure SP-Initiated SAML between Salesforce and Okta
あたり、今までならIdP Initiated SSOでアクセスできたら終わり、と思ってしまってました。
今回、前段の2.や3.を経て、サービス連携先でSalesforce（SP）ログイン画面からSSOさせる必要もあるかもしれない、と気づきました。
例えば、Google Workspace（GWS）、Salesforce、どちらもIdP Initiated SSOに対してサービス側（SP）からアクセスするとGWSはアクセスできます。これは裏側でSP Initiated SSOの動きも兼ねているのか分かりませんが・・・。ちなみにSalesforceは無理でした。
推測ですが、Salesforce側からアクセスするにはSP Initiated SSOの設定も必要という手順なのかもしれません。使うケースとしては前段3.のSalesforceと連携させているサービス側からSalesforceへログインする場合などでしょうか。
この仮説通りだとして、有識者の方がその仕組を解説しても理解できず、結果的に頭には残りませんでした。これまでの経験を経て、重要さを深く理解できるようになりました。公式マニュアルには回りくどい書き方をしているものが多く、読み飛ばしがちですが、改めて注視しようと再確認しました。
参考にしたサイト
Oktaを触りはじめて設定や仕組みを再確認した3ヶ月、基礎の情報を始め色々なサイトを探っていきました。
その中でもLINE WORSK Developersのドキュメントは、細かい部分までカバーしつつも、全体的に分かりやすい表現で書かれており、知見を深める大きなきっかけになったサイトでした。
この記事が気に入ったらサポートをしてみませんか？