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

2023/2/21 5:332023/2/21 5:37

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

https://zenn.dev/kaijnari/articles/e5e26df46d6d8b