何番煎じ感は否めませんが、自身の学びのためにアウトプットするものですのでご了承ください。
そもそもSAMLって何？ 
SAMLは Security Assertion Markup Language の略称で、XMLの形式で定義された認証のための情報です。
これをサーバ間でやりとりすることで、認証を実現します。
XMLの中には、暗号化、署名の方式や証明書、Issuer、Assertionなどが記載されています。
定義したのはOASISという非営利団体で、2005年にリリースされたSAML 2.0が標準になっています。
じゃあSAML認証って何？
登場人物は、以下の3人です。
- ユーザ：サービスを使いたいエンドユーザ（のブラウザなどのユーザエージェント）
- SP（ServiceProvider）：SaaSなど、サービスを提供する人で、アクセスしてくるユーザが何者か知りたい
- IDP（IdentityProvider）：ユーザ情報を管理していて、ログインの仕組みを提供する
このSP、IDP間で上記SAMLのやりとりを行い、最終的にIDPからSPへユーザの認証情報が渡され、ユーザはサービスを利用できるようになります。
複数のサービス（SP）に対して、IDPは1つで良い（=アカウントも1つあればいい）のでSingle sign-on(SSO)だと言われます。
認証の流れ、、、の前に 
SAML認証では実際の認証プロセスの前に、SPとIDP間でmetadataと呼ばれるXMLを交換する必要があります。ここで、何を暗号化・署名するか、どういったアルゴリズムで行うか、公開鍵などを事前に共有します。
交換の仕方はSP/IDPによって様々なようです。
認証の流れ 
SAML認証のフローには、下記2つの始め方があります。
- SP-Initiated：ユーザは、まずSPの特定のURLを踏むところから始まる（例えばSaaSのログインページ）
- IDP-Initiated：ユーザは、いきなりIDPの特定のURLを踏んで、ログインするところからはじまる
ここではSP-Initiatedを選択しています。
また、SP/IDPのやりとりの方法（バインディング）にも下記の種類があります。
- HTTP-Redirect：URLパラメータにSAML情報を仕込んでやりとりする
- HTTP-POST：RequestBodyのSAML情報を仕込んでやりとりする
- HTTP-Artifact：ArtifactというIDを作成し、次のSOAPのような直接通信でやりとりするらしい
- SOAP：SP/IDP間に直接通信パスがある場合に使われるらしい
ここではHTTP-POSTのやり方を選択します（Redirectの場合、Html FormをPostする部分がRedirectになる）。
初回アクセス時の認証フローは下図の通りです（セッションが保存された２回目以降のアクセスの場合、ログイン画面での認証情報入力を省略できます）。
署名はリクエスト・レスポンス共に実施し、暗号化はレスポンスのみ実施しています。
SP開発時に便利なあれこれ 
Chrome extension - SAML Tracer
SAMLのやりとりをトレースできるGoogleChrome拡張。
jsonファイルでExport/Importできて便利 
Onelogin - SAML Developper tools
Code/Decodeや署名、検証など、SAMLのデバッグに重宝するサービスがカテゴライズされて提供されています。
便利
Docker container image - test-saml-idp
ApacheにSimpleSAMLphpを抱き合わせた構成になっていて、すぐ立ち上げてIDPとしてテストできました。また、ここに書かれていない設定をしたい場合、SimpleSAMLphpのドキュメントを見ながらphpを書いて、volume mountすれば反映できました。
便利
まとめ 
わかりやすくまとめたつもりが、全体的に薄いですね 