🌟
IdPとシングルサインオンを実装するときに考えるステップ
これは何？
IdPでSCIM等プロビジョニングとセットで考える時のお助けマニュアルです。
まずは、実装時と、実装後の運用プランはワケて考える必要があります。
用語の整理
- SP : サービスプロバイダー、SaaS側の事
- IdP : IDプロバイダー、OktaやOnelogin,AzureAD等
SSOを実装する前の確認すること
SSO連携した時のSP側のふるまいを確認する。
- 必ずSSO経由じゃないと駄目なのか。
- 特定アカウントをバイパスする事ができるのか？
- 管理者アカウントのログインのふるまいが変わるのか？
- 一般ユーザのID、パスワードによるログインを拒否できる
必ずSSO経由の場合
- 一番厄介なのは、「必ずSSO経由」が強制化される時。後述するけど
共有アカウントの扱いを決めるのに難易度が高くなる。 - 管理者もIdP側で障害発生した場合にアクセスできなくなってしまうので、できる限り避けたい。
特定アカウントをバイパスする事ができるのか？
- 共有アカウントが残置する場合に、その設定を実施する。
管理者アカウントのログインのふるまいが変わるのか？
- SSO後も管理者は常にバイパスされる設定になることもあります。
- SAMLを通らないログインURL等を準備されているSPがあります。
一般ユーザのID、パスワードが拒否できるか？
- これ出来ないと、SSOによるセキュリティへの寄与が少ないので、事前に確認しておきましょう。
既存アカウントのクリアランスを行う。
以下の内容を確認するようにして下さい。
- SP側に退職者が居ないか？
- IdPにアカウント持ってない人は居ないか？
- 共有アカウントがないか？
- ログインID（多くの場合、Email）が、想定しているドメインなのか。
- 社名変更前のドメインでログインしている人とか割といる。
- 外部ID（Gmailとか）だけど、メンバーとしてログインしている等。
- 同じテナントに有償ライセンスと、無償ライセンスがある場合（ZOOM、M365等）は、その区分を確認しておく
SP側の退職者について
- 不要アカウントであれば削除するで良い
- Ownerに紐付いちゃって。。ってパターンは整理が必要。問題ない状態にしてから削除しましょう。
- 最新の社員名簿などと連携してDiff確認するのが良いと思います。
IdPにアカウント持っていない人
- IdP側のアカウントをExportして、Diff確認するのが良い。
- この時に、共有アカウント、ログインIDが想定していない人など見えてくる。
- Idpにアカウントない人は、発行してあげてセットアップをしてあげる。
共有アカウントの対応
- 一番良いのは
廃止できるなら、廃止すること。 - 出来ない場合の選択肢は２つです。
- SSO対象外にできるSPなら、対象外にして引き続きIDとパスワードでのログインをする（現状通りの運用）
- IdPアカウントレベルで共有化する。
- ただIdPで共有アカウントにしてしまうと、Oktaなどではふるまい検知でMFAが通らないことが有り得ます。
ログインIDが想定のアカウントではない場合
- 旧社名のドメインだったなど、割と見かける。
- SP側でIDやメアドを変更して、IdPのものと一致するようにすると良いです。
ライセンスについて
- IdPからライセンスの状態を設定できるパターンがあるので、状態を保全しておくと良いです。
- 万が一SCIM流しちゃった時にライセンスが剥がれてしまっても、状態を保全しておく事で、元に戻せるようになります。
アサイメントを実施する。
基本的な考え方
- 基本は、アプリ毎にアクセスグループを作成し、必要なメンバーをグループにメンバー追加してアサインする。
- ライセンス体系（有料, 無料など）、管理者ロールなどもSCIM経由でSP側に設定できる場合、専用にグループを作っておくと良い。
参考：Oktaで、Google Workspaceにライセンスを配る設定の場合
参考：OktaでGroupアサインする場合
（細かい話） A さんが２つのグループで重複している場合、どっちが先に評価されるか？は、Priorityで制御できる。
プロビジョニングについて考える
SSO実装後のSP側のアカウントの扱い
以下の３つパターン
- SCIM プロビジョニングの自動化
- Just in Time Provisioning
- アカウント作成されない（できない）
SCIMプロビジョニング
- アプリケーションを割り当てすると、自動的にアカウントが作成される。
- IdP側で割当を解除した時の動作（削除 or 無効化）はSP側の仕様に依存する
- IdP側グループも、SP側にリンクする事ができる事がある。
- その場合、SP側でグループで権限設定しておく事で、事前に権限設定等が終わっている事もできる。
ジャストインタイムプロビジョニング
- 初回アクセス時にアカウントが作られるパターン。
- アカウント作成は、初回アクセス時に作成される。
- 前もって、SP側のグループやら何やらの設定ができない。
- アカウント削除はできない。
- SAML認証を必須化出来ない場合は、都度棚卸しが必要になる。
- なので、必須化は大事
- 必須化したとて、アカウント数課金などコスト観点で適宜消す必要がある。
アカウント作成されない
- アカウント作成を別途SP側で手動で行って、IdP側で人をアサインするパターン
- SAML認証を強制化することで、セキュリティ向上には寄与する。
- IdPでアカウントを無効化すると、少なくともアクセスできない状態を作ることができる。
SSOを実装する時、した後
ユーザ影響について伝える
- 主に
SP-Initiated ログイン（SP側からログインする）の場合に、体験が変わるので、どう変わるのか？を調べて伝えておくのが良いかな。 - 正しく設定できてるなら、あまり心配する必要ないかなって実感。
失敗するパターン
- SP側に設定されているアカウントがIdP側にアサインされていない。（一部が漏れているなど）
- SSO設定が正しくできていない
- SAMLの場合は、各パラメーターがあっていない等を確認すると良さそう
これらは事前にテストしておく事ができるので、確認できた状態ですすめると良いですよね。
SSO実装したら、ユーザ割当を自動化する方向で考える
ユーザにアプリケーションへ自動で割り当てるには
- あるSaaSを使う人って、ある程度定義できるものと考えています。
- 自然言語で定義できると、設定がしやすいです。
例として、 Slack の場合。
定義（サンプル）
- 正社員、契約社員、アルバイト、派遣社員は必ず利用します。
設定内容
- 各雇用形態ごとのグループを作成しておく。
- それをそのままアサインしても良い。（が、やや密結合）
- プロフィールに属性情報がある場合は、条件グループ設定でアプリ毎に定義しているグループに自動的に追加される設定を行うと良いです。
という感じ。 ZOOMだと、フィールドセールスで且つ正社員とか。ロールを定義したら、そのロールごとのグループを作ってあげると楽になるのだ。
ユーザ割当を自動化できない時どうするの？
例外ケースを整理する
- Oktaの場合、セルフサービス を使ってユーザからリクエストを上げてもらって、割当を楽にする設定を入れておきましょう
- 手動や、社内のワークフロー経由で依頼を受け取る設定しておいても良いよね。
以上です。またTipsを思い出したら追記します。
Discussion