SAML（Security Assertion Markup Language）の概要
異なるドメイン間でユーザー認証情報をやり取りするためのXMLベースの標準規格である。
主にSSOの仕組みを実現するために利用され、企業や組織のクラウドサービス、Webアプリ間の認証や認可に用いられている。
認証（Authentication）と認可（Authorization）の違い
| 項目 | 説明 |
|---|---|
| 認証（Authentication） | ユーザーが「本当に本人なのか？」を確認すること |
| 認可（Authorization） | 認証されたユーザーが「何ができるか」「どのリソースにアクセス権限があるのか」を決定すること。所謂、管理者権限の割当やアクセス制御が認可であるといえる。 |
→SAMLは主に認証を担っている仕組みである。（厳密にいうと認可も一部サポートする。）つまり本人かどうかを確認するということ。
SAMLのメリット
・SSOによる利便性向上。
・セキュリティ強化。
・アクセス管理の一元化。
SAMLのデメリット
・設定が複雑。（XMLベースだから）
・モバイル対応が弱い。（SAMLはweb向け！）
・リアルタイムのセッション管理が困難。（SAMLにはトークンを動的に更新する仕組みがないので）
具体的な仕組み（SSOの流れ）
SAMLに出てくる3人の登場人物
| 名前 | 説明 | 例 |
|---|---|---|
| ユーザー | サービスを使いたい人 | 実世界の私達（学生、社会人など） |
| IdP(アイデンティティプロパイダー) | ユーザーを確認するシステム | Google,Azureなど |
| SP(サービスプロパイダー) | 実際に使いたいサービス | Gmail,AWSなど |
IdP Initiated SSO(IdPからログインする場合)
これは、ログイン管理システムに入ってから各サービスを使うパターン（Google cloudをイメージしてもらうとわかりやすいと思います。まずはGoogle cloudにログインして任意のAPIを使ったり、クラウドサービス使ったり、、、というようなイメージ。）
1.ユーザーがIdPにログイン
→ （例：Google Cloudにログイン）
2.IdPが「この人はOK！」と判断
→ SAMLアサーション（証明書みたいなもの）を作る！
3.SAMLアサーションをSP（サービス）に渡す
→ （GmailやAWSなどに自動ログイン！）
SAMLアサーションの中身などを知りたい人向け！
このサイトめっちゃ分かりやすいです！
SP Initiated SSO（SPからログインする場合）
1.ユーザーがSPにログイン
→（例：Gmailのログインページを開く）
2.SPが「この人のIdPに確認しよう！」とIdPへリダイレクト
→（例：Googleが「この人、どこでログイン管理されてるんだ？」と探す）
3.IdPが「OK！」と判断して、SAMLアサーションをSPへ送る
→ (結果、Gmailにログインできる！)