0
0

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?

SSOの仕組み(Part1)

Last updated at Posted at 2024-09-12

概要

最近、SSO設定することが多くなってきたのでSSOの仕組み(基本)をここにまとめることにする。細かい設定値などはシステムごとで異なるので、システムごとで逐次確認すること。

SSO(Single-Sign-On)とは?

【定義】
一つの認証情報(ID、PW、ユーザー名、メールアドレス等の組み合わせで使用)を使用して複数のクラウドサービスへログインできるようになること。

通常のログイン時とシングルサインオンを採用した場合の違いについてイメージ図があったので添付する。

image.png

引用元:シングルサインオン

SAML認証とは?

【定義】
SSO認証を行う際に使用するプロトコルのこと

SSO認証する際に使用する情報をXML形式でSPとIdP間で連携してやり取りをすることでスムーズにSPへアクセスできるようにする。

やりとりする情報に関しては主に以下がある。

  • 認証アサーション
    • ユーザーのログインした時間、場所、認証方法(PW、多要素認証?)
  • 属性アサーション
    • 名前、年齢、メール、決済情報等
  • 認可アサーション
    • 特定のファイルやフォルダへのアクセス権限が付与されているのか?などの情報を記載したもの

SSOのメリット

  • ユーザー観点
    • ID、PW管理が楽になる
      • ID、PWの使いまわしを減らせる
      • 複数のクラウドサービスへのログインに手間がかからない(一つのID、PWで良いので)
      • 入力間違いによるロックアウトも減るので、業務効率が上がる(実感ないけど...)
  • 情シス管理者観点
    • 業務工数が減るので、他の仕事へ手が回せる(以下のような手間が省ける)
      • システムロックの解除
      • PWの初期化
      • ID、PWの確認、伝達
    • セキュリティの向上につながる
      • IdPの情報と紐づけるので外部からのアクセスされる可能性を抑えられる (情報漏洩のリスクを減らせる)

SSOのデメリット

  • ユーザー観点
    • 一つのID、PW情報を紛失、失念しないように管理に気を付ける
    • 紙での管理はソーシャルエンジニアリングになるのでご法度
    • PW情報を紛失した際に連携しているサービスにすべてアクセスされる危険性がある
  • 情シス管理者観点
    • ユーザー目線でのPW紛失もそうだが、全社員のPW情報紛失した際の第三者のアクセスの危険性も孕んでいる
    • 使用しているIdPと連携できるサービスではなかった場合の工数増加
      • 別の方法でのアクセスを考える必要がある
    • IdPのシステムダウンによる業務停止の可能性がある
      • ユーザーへのアナウンスや原因調査等が必要になることも?(基本的な調査はIdP提供側で行うが、情報提供を求められた際は工数がかかる)

SSO認証の流れ

SSO認証は主に2種類存在している。それぞれの認証方式の説明は以下の通り。

  • IdP Initiated SSO
    • Azure ADやActive Directoryのようなユーザーを一括管理しているサービスから認証を行う方式
  • SP Initiated SSO
    • 紐づけたクラウドサービスから認証を初めて、IdP(AureADやGWS等)にリダイレクトして認証を行う方式

究極いうと両者の違いは、
紐づけたクラウドサービスから認証を始める? or IdP側から認証を始める? である。
※認証を始める順番がどちらになるか?なので、そこまで深く考える必要は無いかも?それよりもそれぞれ、どういう認証の順番だったかイメージを付けられるとなお良い。。

一応、以下にイメージ図と文字ベースで簡潔に載せる。

IdP Initiated

IdP Initiatedの認証の流れは以下のイメージ。

※文字ベースでの説明と添付の画像の順番はリンクしていないです....

①IdPのログイン画面を開く
②IdPのログイン情報を入れて(ID、PW等)認証を行う ※IdP側での認証
③②での認証が通ると、連携しているSPが一覧で表示される ※ユーザー or グループごとでアクセスさせるSPを制限できる
④アクセスしたSPを選択する
⑤SPのログイン画面へ遷移する(リダイレクトする)
⑥⑤にてSP側での認証を行ったのちにログインできるようになる ※連携するSPによってはID、PWを入力するケースも?

image.png

SP Initiated

SP Initiatedの認証の流れは以下のイメージ。

※これも文字ベースでの説明と添付の画像の順番はリンクしていないです....

①IdPとSSO連携したSPのログイン画面を表示する
②ログイン情報(ID、PW等)を入れる
③IdPの画面へリダイレクトする(ここで認証情報を精査している)※ID、PW情報の入力は求められないです...多分
④IdP側での認証が通ると、SPへログインできる

image.png

いかがだったでしょうか?上記の通りどちらから認証を始めるか?の違いしかないので、使用しているIdP画面やSPの画面をイメージしながら連携業務にあたってもらえれば良いかと。。。。

引用元:SSO認証のイメージ

SSOする前に

最後にSSOを実装する際にいきなり実装、導入ではなくその前に考えておくべき事項等について整理していくことにします。不足している情報があるかもしれないですが、ご参考までに。

  • 連携したいSPがIdPに対応しているのか?

    • アカウントプロビジョニングまでできるのか?
      • 事前にSP側でアカウント作成が必要な可能性ありな場合も。。。
    • そもそもSSO連携できるのか?手順やマニュアルは存在する?
  • SP側でIdPに必要な設定情報を取得することはできる?※条件を満たせばSSOできる可能性あり

    • ACS URL
    • NameID
    • NameIDフォーマット
    • SP Issuer等
      参考:HENNGEの例
  • IdP側で取得できる情報がSPでの設定要件を満たしているのか?

    • 上記の逆バージョン
  • 検証環境を用意する

    • システム内などに限定など工夫して動作検証を進めて想定している動きであれば、本番導入を行う

まとめ

こんな感じで1回目の説明を終えたいと思います。
そういえば、SSOってなんだっけ?SSOするメリットって?目的は?等が分からなくなったときは見返す程度で。。。
次は具体的なSSO認証の種類の説明に入っていきますね。

参考資料

0
0
0

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
0
0

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?