🌟

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

2022/06/17に公開約3,600字

これは何?

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にアカウントない人は、発行してあげてセットアップをしてあげる。

共有アカウントの対応

  • 一番良いのは 廃止 できるなら、廃止すること。
  • 出来ない場合の選択肢は2つです。
    • SSO対象外にできるSPなら、対象外にして引き続きIDとパスワードでのログインをする(現状通りの運用)
    • IdPアカウントレベルで共有化する。
  • ただIdPで共有アカウントにしてしまうと、Oktaなどではふるまい検知でMFAが通らないことが有り得ます。

ログインIDが想定のアカウントではない場合

  • 旧社名のドメインだったなど、割と見かける。
  • SP側でIDやメアドを変更して、IdPのものと一致するようにすると良いです。

ライセンスについて

  • IdPからライセンスの状態を設定できるパターンがあるので、状態を保全しておくと良いです。
  • 万が一SCIM流しちゃった時にライセンスが剥がれてしまっても、状態を保全しておく事で、元に戻せるようになります。

アサイメントを実施する。

基本的な考え方

  • 基本は、アプリ毎にアクセスグループを作成し、必要なメンバーをグループにメンバー追加してアサインする。
  • ライセンス体系(有料, 無料など)、管理者ロールなどもSCIM経由でSP側に設定できる場合、専用にグループを作っておくと良い。

参考:Oktaで、Google Workspaceにライセンスを配る設定の場合

参考:OktaでGroupアサインする場合
(細かい話) A さんが2つのグループで重複している場合、どっちが先に評価されるか?は、Priorityで制御できる。

プロビジョニングについて考える

SSO実装後のSP側のアカウントの扱い

以下の3つパターン

  • 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

ログインするとコメントできます