認証方式って多くて覚えるのがたいへんですよね。
私も毎回毎回ググって「ああ、こんな感じだったな…」と思いながら、日々を過ごしています。
特にSaaSにおいては、複数の認証方式をサポートしていることが多く、忘れたころに問い合わせが来たりして脳内にロードするためのコストを毎度払っています。
今回は、脳内へのロード時間を減らすためにSSO/SAMLにおけるざっくり概念を書き残しておきます。
SSOとSAMLとは何か?
まずはSSOとSAMLの概念を整理します。
- SSOとは、一度のユーザー認証によって業務アプリケーションやクラウドサービスといった、複数のシステムの利用が可能になるしくみ
- SAMLとは、 Security Assertion Markup Languageという、Webアプリケーションのシングルサインオン (SSO) を実現するXMLベースの規格
標準化団体のOASISの文書にもしっかりと規格が記載されていますね。
登場人物の整理
| 登場人物 | 説明 |
|---|---|
| ユーザー | 認証を受けるユーザー |
| ID Provider（IdP） | ユーザーIDを提供するもの。ユーザーの認証情報を含む"Assertion"の発行等のSAMLのやりとりを司る |
| Service Provider（SP） | Webサーバを提供するもの（= SSOで認証されるサーバ）当然SAMLに対応している必要がある |
SaaSにおいては、以下のような関係性になります。
大まかなSAMLフロー
SP-initiated SSOやIdP-initiated SSO等の詳細な認証フローについては他サイトに譲るとして、ここでは大まかなSAMLフローについて記載します。おおきく以下2つの流れで構成されています。
-
IdPに対してSAMLの認証リクエストを投げる
-
SAMLの認証レスポンスを用いてSPに認証を求める
詳細なシーケンスについてはこちらのサイトがわかりやすいと思います。
SAML認証レスポンスに含まれるフィールド
主なフィールドとして、以下が含まれます。
| フィールド | 説明 |
|---|---|
| アサーション（Assertion） | ユーザーの認証情報 |
| ステータスコード（Status Code） | 応答の成功、失敗、そのほかのステータスを示す |
| 発行者（Issuer） | 応答を生成したエンティティの識別子 |
| ユーザー情報（Subject） | 認証されたユーザーの識別情報 |
| 署名（Signature） | 応答の真正性を保証するためのデジタル署名 |
署名・暗号化の箇所を詳細にみてみる
SAMLにおける署名/暗号化は主に2種類あります。ちなみに併用が可能です。
- デジタル署名
- Assertionの暗号化
1. デジタル署名
これはデジタル署名の目的そのもので「本当にIdPから来たSAML Assertionなのか？」を解決するための策となります。
オリジン/送信元であるIdPのなりすまや通信経路上での改竄を防止し、SAML Assertion・リクエスト・レスポンスなどのメッセージの完全性を保証します。
Assertionを含むレスポンスが、ユーザーのブラウザを介して届けられる場合は、デジタル署名が義務付けられています。 SaaSでのユースケースにおいては、必須と言って良いでしょう。
必要な証明書
- トークン署名証明書
2. Assertionの暗号化
通信路上においてAssertionが漏洩した際に、SAML Assertionが漏洩・改竄することを防ぐための策となります。
中間者攻撃や傍受攻撃を防止し、SAML Assertionの秘密性を保証します。
SAMLは、HTTPS（HTTP over SSL/TLS）で暗号化された状態で使用することが推奨されています。 つまり、リクエストおよびレスポンスは（Assertionの暗号化を行わなくとも）HTTPSの範囲においての暗号化はすでに行われています。
それに加えてAssertionの暗号化を行うことで、受信者である特定のService ProviderのみがSAML Assertionの内容を解読できるようにし、よりセキュアにやりとりができるようしくみを提供しています。
必要な証明書
- トークン暗号化解除証明書
参考文献
株式会社オープンエイトのテックブログです！カジュアル面談大歓迎ですー！エンジニア積極採用中 👉 open.talentio.com/r/1/c/open8/homes/3396
Discussion