【SAML】シングルサインオン(SSO)の動作概要

セキュリティ

複数のSaaSアプリを利用する場合、SaaSアプリ単位にID、パスワードを管理する運用は非常に困難です。ユーザにとっては、異なるSaaSアプリを使用するたびにID、パスワードを入力、および管理する必要があり、ユーザビリティが低下します。もちろん、管理者にとっても複数アプリに跨り、ID管理することは大変な負担です。

SAML(Security Assertion Markup Language)とは一度のユーザ認証により、異なる組織へのアプリケーションにも認証無しで使用(シングルサインオンでログイン)できる仕組みで、XML仕様のマークアップ言語です。

SAMLに伴い、中央のID管理システムにより1度認証されたユーザは、複数のSaaSアプリへシームレスにアクセスすることができます。

スポンサーリンク

SAMLの概要

SAMLの登場人物として、IdPSPがあります。

IdP(IDプロバイダ)は、ユーザIDやパスワードなどの認証情報を保持しているサービスのことで、SP(サービスプロバイダ)は、いわゆるSaaSアプリのことです。

SaaSアプリ(SP)を利用する際に、IDプロバイダ(IdP)で認証をして、認証OKだったら、SPに接続させます。

通常は、IdPとSPは異なる組織(ドメイン)になります。例えば、IdPで有名なのは、AzureADOktaPingFederation, JumpCloudなどがあり、SP(SaaSアプリ)は、Microsoft365Box など、多数存在します。

IdPSPは異なる組織のため、予め信頼関係を結ぶことで、IdPが認証OKとなれば、それをSPで信用します。この信頼関係は、PKIの仕組みを使用しています。

例えば、IdPを認証局として、証明書を発行し、SPへインポートします。IdPから送信される認証結果(アサーション)にIdPの署名をつけて、SPはIdPから発行された証明書の公開鍵で署名を検証します。

署名の仕組みは、以下の記事も参考にしてください。

  >> 参考記事 :  【初心者】公開鍵暗号、認証局、デジタル署名をイメージで解説
スポンサーリンク

SAML処理フロー

ユーザがあるSaaSアプリに接続してから、シングルサインオンによりアプリへの接続ができるまでのフローは以下のとおりです。

  1. クライアントは、ブラウザ等よりSP(SaaSアプリ)へ接続します。
  2. SPは、予め設定されたIdP(サインオンURL)へリダイレクトするよう、クライアントへ要求します。
  3. クライアントはサインオンURLへ接続します。サインオンURLの接続先はIdPです。
  4. IdPよりユーザIDとパスワードの入力を求められます。ここで、ユーザIDとパスワードを入力します。
  5. 認証がOKであれば、ユーザに紐づいた属性値などを含めたアサーションを付与し、予め設定されたSPのSSOモジュール(応答URL)へリダイレクトするようクライアントへ要求します。
  6. クライアントは、応答URLへ接続し、SPへアサーションを提供します。
  7. SPはアサーションを受信し、信頼関係のあるIdPからの署名であるのか検証します。
  8. 検証OKで、ユーザを受け入れる場合は、クライアントへSaaSアプリにリダイレクトするよう要求します。
  9. クライアントはSaaSアプリへ接続開始します。
  10. アクセスが成功します。

SaaSアプリが複数あっても、ユーザがIdPで認証済みであれば、アサーションを提供することで、ユーザIDの入力無しに複数SaaSアプリへのアクセスが成功します。

スポンサーリンク

SAMLで使用するパラメータ

IdPSPでは、例えば、以下のようなパラメータが発行されます。

基本的に、IdPで発行されたパラメータは、SPへインポートし、SPで発行されたパラメータは、IdPへインポートします。これによりIdPとSPとの信頼関係が結べます。

IdPで発行されるパラメータ

  • サインオンURL(ログインURL/ログアウトURL)
  • IdP識別子(エンティティID)
  • SAML証明書(アサーションの署名用)

SPで発行されるパラメータ

  • SP識別子(エンティティID)
  • 応答URL
  • サインオンURL/ログアウトURL

実際の設定は、IdP、SPそれぞれで公開されているドキュメントを参照しながら、実施します。

コメント

タイトルとURLをコピーしました