IdPとシングルサインオンを実装する時に考えるステップ

「IdPとシングルサインオンを実装するときに考えるステップ」をZennに公開しました。 考えるステップになりますので、初めて作業をするときに参照頂きたいTipsになります。
 
詳細は Zenn をご確認ください。
IdPとシングルサインオンを実装するときに考えるステップ
IdPでSCIM等プロビジョニングとセットで考える時のお助けマニュアルです。 まずは、実装時と、実装後の運用プランはワケて考える必要があります。 用語の整理 SP : サービスプロバイダー、SaaS側の事 IdP : IDプロバイダー、OktaやOnelogin,AzureAD等 必ず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にアカウントない人は、発行してあげてセットアップをしてあげる。 共有アカウントの対応 一番良いのは 廃止 できるなら、廃止すること。 出来ない場合の選択肢は2つです。 SSO対象外にできるSPなら、対象外にして引き続きIDとパスワードでのログインをする(現状通りの運用) IdPアカウントレベルで共有化する。 ただIdPで共有アカウントにしてしまうと、Oktaなどではふるまい検知でMFAが通らないことが有り得ます。 ログインIDが想定のアカウントではない場合 旧社名のドメインだったなど、割と見かける。 SP側でIDやメアドを変更して、IdPのものと一致するようにすると良いです。 ライセンスについて IdPからライセンスの状態を設定できるパターンがあるので、状態を保全しておくと良いです。 万が一SCIM流しちゃった時にライセンスが剥がれてしまっても、状態を保全しておく事で、元に戻せるようになります。 基本的な考え方 基本は、アプリ毎にアクセスグループを作成し、必要なメンバーをグループにメンバー追加してアサインする。 ライセンス体系(有料, 無料など)、管理者ロールなどもSCIM経由でSP側に設定できる場合、専用にグループを作っておくと良い。 参考:Oktaで、Google Workspaceにライセンスを配る設定の場合 参考:OktaでGroupアサインする場合 (細かい話) A さんが2つのグループで重複している場合、どっちが先に評価されるか?は、Priorityで制御できる。 以下の3つパターン SCIM プロビジョニングの自動化 Just in Time Provisioning アカウント作成されない(できない) SCIMプロビジョニング アプリケーションを割り当てすると、自動的にアカウントが作成される。 IdP側で割当を解除した時の動作(削除 or 無効化)はSP側の仕様に依存する IdP側グループも、SP側にリンクする事ができる事がある。 ...