SAMLを実装する。のバックアップ(No.2)

SP/IdP
- Identity Provider（IdP）
  - 認証・認可の情報を提供する役割を担う。
  - IdPで認証されたユーザーは SP のサービスにアクセスできるようになる。
- Service Provider（SP）
  - シングルサインオン対象の Web アプリケーションなどを意味する。
  - IdP が発行した認証・認可の情報に応じてクライアントにサービスを提供する。

トラストサークル（Circle Of Trust）
- IdP と SP の間で結ばれた信頼関係を意味する。
- シングルサインオンを実現するためには、
  IdP と SP との間で事前に信頼関係を結んでおく必要がある。
- IdP-SP 間でお互いを事前に登録し、お互いの証明書を交換する。
- 一つのトラストサークル内に複数の IdP が存在することもある

※同じ言葉でも、他のプロトコルでは意味が違うことがあるので注意

アカウント連携
- IdP のアカウントと SP のアカウントを紐付ける
- NameID というユーザー識別子を IdP と SP 間で共有することで実現する
- NameID には以下のものが使用される
  - メールアドレス
  - ユーザー名
  - GUIDなどの識別子
  - X.509 の Subject

↑

シーケンス †

認証シーケンス
- SP-initiated SSO
  - ユーザーは最初にSPにアクセスし、IdPでの認証に成功した後に、再びSPにアクセスする。
- IdP-initiated SSO
  - ユーザーは最初にIdPにアクセスし、IdPでの認証に成功した後にSPにアクセスする。
  - SAML RelayState?というパラメタに遷移先情報を埋め込む。

メッセージの送受信方法
- HTTP Redirect/HTTP POST Binding
  - IdP-SP間の直接的な通信が発生しない
  - ブラウザが通信を中継する（HTTP Redirect/HTTP POST を利用）
- HTTP Artifact Binding
  - IdP-SP間の直接的な通信が発生する
  - アサーションへのリファレンスである Artifact をブラウザを介してIdPとSPの間で送受信する。
    IdPと SP は Artifact を利用して直接相手に SAML 認証要求/認証応答メッセージを問い合わせる。
  - Artifact のデータサイズは小さい。

↑

SAMLアサーション †

事前に IdP の証明書を SP に登録しておく必要がある（JWTみたいなもの）

<saml:Assertion xmlns:saml="urn:oasis:names:tc:SAML:2.0:assertion"
  Version="2.0"
  ID="s2907181983bc6f588aeb045fca183d671224506ec"
  IssueInstant="2009-11-18T08:28:09Z">
    アサーション発行者
    アサーションのデジタル署名
    ユーザー識別子(NameID)
</saml:Assertion>

↑

認証要求・認証応答 †

認証要求（AuthnRequest?）
SPがIdPに対して、ユーザーの認証情報（アサーション）を要求するメッセージ

<samlp:AuthnRequest ID=”xxx” Version=”2.0”
 Destination=”http://idp.osstech.co.jp/idp/sso”>
    認証要求情報
</samlp:AuthnRequest>

認証応答（Response）
IdPがSPにユーザーの認証情報（アサーション）を送付するメッセージ

<samlp:Response ID=”xxx” Version=”2.0”
 Destination”http://sp.osstech.co.jp/sp/sso”>
    < saml:Assertion ...>
        アサーション
    </saml:Assertion>
</samlp:AuthnRequest>

↑