適当おじさんの適当ブログ

技術のことやゲーム開発のことやゲームのことなど自由に雑多に書き連ねます

SAML SSO 設定後の注意点まとめ

SaaS

この1,2年で、さまざまなアプリケーションにSAML SSOを設定してきました。たくさん設定するうちに自分の中でチェックポイントがパターン化できてきたので備忘録的に残しておきます。

この記事では、SAML SSOを設定したあとの注意についてまとめています。SAML SSOの設定だけで満足せず、もう一歩踏み込んでSP(Service Provider)の仕様を確認することで、認証周りをよりセキュアにできる可能性があります。SP側のSSO関連の細かい仕様・設定は統一されておらず、割とバラつきがあるためです。新しくSSOを設定することになった場合、以下のポイントに気を付けています。

  • SSOを強制できるか
  • 必要に応じてSSO以外の認証ができるか
  • 特定ドメインのサインアップを禁止できるか
  • SSO時にJITプロビジョニングされるか
  • 自分たちだけでSSO設定できるか

それぞれの詳細と具体的な確認ポイントについて触れていきます。

SSOを強制できるか

最近のサービスは、ユーザーに「ID/パスワードでのサインイン」や「Googleでサインイン」といった複数の認証方法を提供していることが多いです。ユーザー目線だと便利で嬉しいのですが、情シス目線では認証の口が複数ある状況はあまり好ましくありません。

一部のSPでは認証方法をSSOだけに制限＝SSOを強制させることができます。SSOを設定した時点で自動的に強制になったり、明示的に「強制を有効化」する必要があったり、そもそも強制できなかったりと振る舞いはSPによって様々です。

可能なら強制しておくに越したことはないと思います。強制できないけど推奨したい場合、「SP側のユーザーパスワードを教えない」「IdP-initiatedしてもらう」など運用でカバーする必要があります。

確認事項
  • SAML SSO設定を有効化したタイミングですぐにSSO強制されるか
  • SSO強制のために明示的な設定が必要か
  • SSO強制できない場合、SSOに誘導できるような運用を考えたか

必要に応じてSSO以外の認証が選択できるか

原則SSOを強制しつつも、特定のケースでのみパスワード認証を許可したいケースもあります。例えば、管理者のみパスワード認証できるようにしておくことでIdPの問題発生時にサインイン＆調査できて便利です。やんごとなき事情でパスワード認証しないといけないケースもあります。

Atlassian Acessでは、認証ポリシーを定義してある条件下でのみパスワード認証にできます。Google Workspaceの場合は、特権アカウントはパスワード認証しか利用できません。SSO強制と同じくSPによって仕様がバラバラです。SPごとにどれくらい融通がきくのか確認しておきましょう。

確認事項
  • 「特定ユーザー・条件下のみパスワード認証にする」といった認証ポリシーを定義できるか
  • 特権アカウントはSSO・パスワード認証の併用が可能か
  • SSOができなくなり詰んだ場合の問い合わせ先などを把握しているか

特定ドメインのサインアップを禁止できるか

SSOの設定とは直接関係ありませんが、IdPとSPを繋ぐ際に必ずチェックしているポイントです。 「サインアップ禁止&SSO強制」を実現できないSPの場合、フリーアカウントとして勝手にサインアップされてしまう可能性があります。気づいたタイミングでSSO設定したり、自分達のテナントに招待したり、ライセンス付与したりすればなんとかなりますが、後手後手感は否めません。

DocuSignやBoxでは特定ドメインのユーザーのサインアップを禁止できます。例えば example.com ドメインを登録しておくことで、hogehoge@example.com のメールアドレスでのサインアップができなくなります。サインアップを禁止することで、謎アカウントの発生を簡単に防止できます。わざわざ禁止設定しなくても自動で禁止されるパターンもあります。テスト用アカウントなどでサインアップしてみれば手っ取り早く検証できます。

サインアップを禁止すると「とりあえず急ぎで一旦対応」ができなくなり、ユーザー体験が悪化するという見方もできます。問い合わせがあったらすぐにアカウントを用意できるような体制を構築しておきましょう。SCIMプロビジョニングやJITプロビジョニングされるならこの心配はありません。

確認事項
  • 特定のドメインが含まれるユーザーのサインアップを禁止できるか
  • 自由に設定できない場合、デフォルトの挙動は把握済みか
  • サインアップを禁止した場合、ユーザーの利便性を損なわないようなフローを構築できているか。

SSO時にJITプロビジョニングされるか

JITプロビジョニング＝SSOしたタイミングでアカウントがない場合に自動的にアカウント作成する機能のことです。 例の如く、JITプロビジョニングするかどうかはSPによって異なります。デフォルトでJITプロビジョニングされることもあれば、設定でオン/オフできる場合もあります。SPのSAML SSOに関するドキュメントを読んで仕様をしっかり把握しておきましょう。ドキュメントの隅っこにさらっと書かれていることもあるので、テストアカウントでSSOしてみるのが手っ取り早く間違いなく確認できます。

JITプロビジョニングは便利ですが、作成するだけで無効化/削除はできません。SPがSCIMに対応しているのであれば、ちゃんとSCIMを設定してプロビジョニング/デプロビジョニングしたほうが統制が取れて良いと思います。

確認事項
  • デフォルトでJITプロビジョニングするかどうか
  • SP側でオン/オフ切り替えられるか
  • 作成だけでなく、無効化/削除についても考えられているか

自分たちだけでSSO設定できるか

SP側の設定をサービスの提供者にお願いしなければならないケースがあります。昔ながらの国産サービスに多い印象です。コミュニケーションが必要な分、設定完了までにどうしても時間がかかりがちです。また、ここまで述べてきたような仕様がオープンになっていないことも多く、SP担当者に確認しないとわからないこともよくあります。

これに関しては正直どうしようもありません。「自分たちだけで設定できるサービス」と「そうでないサービス」をしっかり把握・整理しておくことが大事だと思います。

Azure AD設定時に気を付けていること

最後に、IdP側で気をつけているポイントについても少し触れておきます。Azure AD で設定する時に気を付けていることを2つだけ書いておきます。

SAML署名証明書の有効期限と通知先に気を付ける

AzureADの場合、有効期限が最大でも3年までしか設定できません。この証明書の期限が切れてしまうとSSOできなくなる可能性があります。可能性がある、という書き方をしたのはSPの実装に依存するためです。SPが証明書の有効期限をしっかりチェックしている場合にのみSSOができなくなります。実際にSSOできなくなり焦った経験もあります。 この件については、以下ブログがとても参考になりました。 jpazureid.github.io

また、デフォルトでは有効期限切れに関するメール通知先が作成者のメールアドレスになっています。とりこぼしがないように、メーリングリストなどを指定しておきましょう。

アクセス管理権限の委譲を検討する

Azure ADの場合、「エンタープライズアプリケーション」か「エンタープライズアプリケーションに割り当てられたグループ」の「所有者」にユーザーを割り当てることで、間接的に「サービスに対するアクセス管理権限」を委譲できます。リスクや統制上の問題がなければユーザーに権限委譲するのもアリだと思います。

アクセス権限を設定する際は、所属する組織やチーム、雇用形態に応じて自動的にアクセス許可するケースが一般的かと思いますが、様々な事情で個別設定しなければならないケースもあると思います。加えて「IdP上のアクセス権限管理は情シスメンバー」「サービス側のユーザー管理は情シス以外の誰か」といった感じで「アクセス管理者≠サービスのユーザー管理者」になってしまうと、管理者間のやりとりが必要になったり設定反映までタイムラグが生じたりしてしまいます。

情シスがすべて管理できれば話は早いのですが、リソースの都合で難しいこともあります。そういった場合に、「所有者」を使った方法でアクセス管理権限も委譲してみると少し幸せになれるかもしれません。