SAMLの仕様を読む。のバックアップ(No.25)

SAMLパーティ間で設定情報を表現および共有するXMLのスキーマを定義
SPがIdPを利用するための情報を記述して、IdPとSPの信頼関係を構築できる。
- エンティティのサポートされているSAMLバインディング
- 運用上の役割（IDP、SPなど）
- 識別子情報、サポートID属性
- および暗号化と署名のための鍵情報

↑

Authentication Context †

認証メカニズムを記述するAuthentication Context宣言を記述するための構文を定義
認証のタイプと強度に関する詳細な情報をSPが要求し、IdPは、これに応答する。
- Authentication Context宣言を作成するためのメカニズムを定義する一般的なXMLスキーマ
- 一般的に使用されるSAMLのAuthentication Contextクラスのセットがあります。

↑

XML Signature Syntax and Processing †

XMLデジタル署名処理規則と構文

↑

ユースケース †

↑

参加者 †

システム・エンティティ
システム・エンティティは、さまざまなSAMLロールで動作するが、
最低限、SAML交換は、以下のシステム・エンティティ間で行われる。

アサーティング・パーティ（SAMLオーソリティ）
- SAMLアサーションを行うシステム・エンティティ
- ユーザもアサーティング・パーティの参加者である可能性がある。

リライング・パーティ（RP）
受け取ったアサーションを使用するシステム・エンティティ

リクエスタ / レスポンダ
- アサーティング・パーティとリライング・パーティは、SAMLリクエスタにもレスポンダにもなりうる。
- アサーティング・パーティの情報に依存するという回答側の意向は、アサーティング・パーティとの信頼関係に依存

ロール

SSOのロール

Identityプロバイダ（IdP）
≒ アサーティング・パーティ（SAMLオーソリティ）

Serviceプロバイダ（SP）
≒ リライング・パーティ

のロール

属性リクエスタ
アイデンティティ属性クエリ

属性機関の役割
アイデンティティ属性クエリに応答してSAMLエンティティがアサーションを生成

サブジェクト≒プリンシパル
- 殆どのSAMLアサーションの中心にある対象
- 通常は人間、それ以外にも会社やコンピュータなどエンティティを表す。

あとは、だいたい、OpenID Connectと同じ。

↑

Web-SSO †

マルチドメインWebシングルサインオン
SAMLが適用される最も重要なユースケース

これも、あとは、だいたい、OpenID Connectと同じ。

↑

IDフェデレーション †

考慮しなければならない多くの質問
- ユーザーは、既存のローカルIDをサイトに持っているか？
- ユーザーの連合IDの確立と終了は静的か？動的か？
- ユーザーは連合IDの確立に明示的に同意する必要があるか？
- ユーザーに関するID属性を交換する必要があるか？
- IDフェデレーションは、SessionIDなどの識別子に依存するべきか？
- 情報が暗号化されるべきか？交換される情報のプライバシーは大きな関心事か？

連合ID機能を強化するための2つの機能
- フェデレーション名識別子の動的確立と管理をサポートする、新しい構成とメッセージ
- プライバシー保護の特徴を持った2つの新しいタイプの名前識別子

プロバイダー間のユーザー情報の維持および更新
- 追加のフローは必要のないケース。
- 追加のフローが必要になるケース。
  SAML V2.0メッセージ交換の外部で行われるケース
  - IdPにおけるデータソースによって駆動され、
  - SPに伝播されるバッチまたはオフラインのIDフィードを利用

↑

アカウントリンク †

連合IDをローカルIDと関連付けるプロセスは、アカウントリンクと呼ばれる。
- IdP検出機能を使用し、SPからIdPにアカウントリンクするかしないかをユーザに問う。
- ユーザが、フェデレーションに同意するとIdPにリダイレクトされる。
- IdPでSPのフェデレーション名識別子が生成され、IdP上のアカウントにリンクされる。
- IdPでSPは、後続のトランザクションでこの識別子を使用してユーザを参照する。
- IdPからSPにリダイレクトされた後、この識別子をSPのローカル・アカウントに関連付ける。

※ 追加のサイトとアカウントリンクする場合は、
　新たにフェデレーション名識別子を生成し、上記手順を繰り返す。

↑

アーキテクチャ †

↑

基本概念 †

↑

基本的なSAMLの概念 †

（Profile（Binding（Protocol（Assertion））））

                     ・Metadata
                     ・Authentication Context

↑

Assertions †

アサーティング・パーティが真実であると主張するプリンシパルに関する
ステートメントを伝えるXMLスキーマによって定義されたアサーション。

リライング・パーティからの要求に基づいてアサーティング・パーティによって作成される。
特定の状況下では、アサーションは未承諾の方法でリライング・パーティに配信できる。

↑

Protocols †

SAMLのリクエスト / レスポンスを行うプロトコル。
これにより、アサーションの入手や、IDマネジメントを行う。

↑

Bindings †

参加者間でSAMLプロトコル・メッセージを転送するために下位レベルの
通信またはメッセージングプロトコル（HTTPまたはSOAPなど）を使用する方法

↑

Profiles †

WebブラウザSSOプロファイルなどの特定のユースケースを満たすように定義される。
SAMLアサーション、プロトコル、およびバインディングの内容に対する制約を定義する。
プロトコルメッセージやバインディングを参照しない属性プロファイルもある。
（X.500 / LDAP、DCEなどの一般的な使用環境と一致する方法でアサーションを使用）

↑

構築と展開の2つの概念 †

SAML Metadata

Authentication Context
Authentication Contextの例

#	Authentication Context	説明
1	urn:oasis:names:tc:SAML:2.0:ac:classes:PasswordProtectedTransport?	パスワードを提示して認証したことを示す
2	urn:oasis:names:tc:SAML:2.0:ac:classes:PreviousSession?	セッション等を使用し、・すでに認証済みであること示す。・過去のある時点で認証したこと示す。
3	urn:oasis:names:tc:SAML:2.0:ac:classes:X509	デジタル署名により認証したことを示す。
4	urn:oasis:names:tc:SAML:2.0:ac:classes:unspecified	不特定の方法で認証したことを示す。

↑

高度な概念 †

Subject Confirmation

Assertionsには、SubjectConfirmation?という要素を含めることができる。

実際的には、Subject Confirmationは、
- Assertionの利用者が許可されている条件
- ≒ SPが検証を行うための手段を提供する。

Method属性に3つの値を定義することによって、
3つの異なるセキュリティシナリオに対応する。

urn:oasis:names:tc:SAML:2.0:cm:bearer
所謂、一つの、持参人切符

urn:oasis:names:tc:SAML:2.0:cm:holder-of-key
SubjectConfirmationData?を使用した、記名式切符

urn:oasis:names:tc:SAML:2.0:cm:sender-vouches
どのRPがそのClaimを使用することを許可されるべきかを決定する際に他の基準を使用

↑

SAML Components †

↑

Assertions †

通常、アサーションは以下から構成される。

アサーションのsubject
- subject（主題）
- subjectが存在しない場合、他の方法で識別される。
  例えばsubjectの確認に使用された証明書

アサーションの検証条件

アサーション・ステートメント

Authentication statements
- ユーザーを正常に認証した当事者によって作成される。
- 最低でも、認証に使用される特定の手段と認証が行われた特定の時間を説明。

Attribute statements
- サブジェクトに関する特定の識別属性
- 例えば、ユーザー"John Doe"は"ゴールドカードステータス"を持つ。

Authorization decision statements
- 対象がする権利があるものを定義する
- 例えば、ユーザー"John Doe"は"特定の品目を購入すること"が許可されている。

↑

Protocols †

いくつかの一般化された要求/応答プロトコルを定義する。

Authentication Request Protocol

以下を含むアサーションを要求できるようにする手段を定義。
- Authentication statements
- Attribute statements

Web Browser SSO Profile
SPからIdPにユーザをリダイレクトするときに使用する。

Single Logout Protocol
- プリンシパルのアクティブ・セッションのログアウト・メカニズムを定義。
- ログアウトは以下の様なエンティティが開始できる。
  - ユーザ（直接開始
  - SP/IdP（Sessionタイムアウト、管理者コマンド

Assertion Query and Request Protocol
アサーションを取得するための一連のクエリを定義

Artifact Resolution Protocol
アーティファクトと呼ばれる小さな固定長の値を使用して、
メッセージを参照によって渡すことができるメカニズムを提供

Name Identifier Management Protocol
- 要求の発行者は、SP/IdPのどちらでもかまわない。
- プリンシパルを参照するために使用される名前識別子に関するメカニズムを提供。
  - 形式を変換する
  - 関連付けを開始 / 終了する

Name Identifier Mapping Protocol

適切なポリシー制御に従って、名前識別子を
別の名前識別子にマッピングするためのメカニズムを提供

アプリケーション統合シナリオでは、あるSPがIdPから
別のSPで使用できるユーザーの名前識別子を要求することを許可する。

↑

Bindings †

トランスポート層上で、プロトコルメッセージをどのように伝達するか？

HTTP Redirect Binding
リダイレクト（302応答）を使用してプロトコルメッセージを転送する方法を定義

HTTP POST Binding
HTMLのformコントロール(base64)でプロトコルメッセージを転送する方法を定義

HTTP Artifact Binding
- Artifact Resolution Protocolを使用して、プロトコルメッセージを転送する方法を定義
- HTMLのformコントロールと、URL中のQuery stringを使用する方法がある。

SAML SOAP Binding
SOAP 1.1を使用して、プロトコルメッセージが転送される方法を定義

Reverse SOAP (PAOS) Binding
- HTTPクライアントをSOAPレスポンダにする多段階のSOAP / HTTPメッセージ交換を定義
- IDPディスカバリをサポートする拡張クライアントおよびゲートウェイ・プロキシで使用

SAML URI Binding
URIを解決することによって既存のSAMLアサーションを取得するための手段を定義

↑

Profiles †

特定シナリオでアサーション、プロトコル、バインディングの組合せ（制約）を定義

Web Browser SSO Profile
標準のWebブラウザでシングルサインオンを実現する

以下の使用方法を定義する。
- Authentication Request Protocol
- SAML Response messages & assertion

バインディングの組合せを定義
- HTTP Redirect Binding
- HTTP POST Binding
- HTTP Artifact Binding

Enhanced Client and Proxy (ECP) Profile
- 特殊クライアントまたはゲートウェイ・プロキシ用の
- Reverse-SOAP (PAOS) や SOAPを使用する特殊SSOプロファイルを定義す。

Identity Provider Discovery Profile
ユーザが以前に訪問したことのあるIdPについてSPが知るためのメカニズムを定義

Single Logout Profile

以下の使用方法を定義する。
- Single Logout Protocol
- SAML Response messages & assertion

バインディングの組合せを定義
- HTTP Redirect Binding
- HTTP POST Binding
- HTTP Artifact Binding
- SAML SOAP Binding

Assertion Query and Request Profile
- 同期バインディング

以下の使用方法を定義する。
- Assertion Query and Request Protocol
- SAML Response messages & assertion

Artifact Resolution Profile

以下の使用方法を定義する。
- Artifact Resolution Protocol

バインディングを定義
- SAML SOAP Binding

Name Identifier Management Profile

以下の使用方法を定義する。
- Name Identifier Management Protocol

バインディングの組合せを定義
- HTTP Redirect Binding
- HTTP POST Binding
- HTTP Artifact Binding
- SAML SOAP Binding

Name Identifier Mapping Profile

以下の使用方法を定義する。
- Name Identifier Mapping Protocol

バインディングを定義
- SAML SOAP Binding

↑

EndPoint? †

この項目は、SAMLの公式資料にはないが、図を見ると、
EndPoint?には以下の様な名称が付与されている。

Single sign-on

SAML Requestを受けるEndPoint?
SSO Service

SAML Responseを受けるEndPoint?
Assertion Consumer Service

Artifact

Artifact Requestを発行するEndPoint?
- SSO Service(RequestでArtifactを使用する場合)
- Assertion Consumer Service(ResponseでArtifactを使用する場合)

Artifact Requestを受けるEndPoint?
Artifact Resolution Service

Single logout

SAML Requestを受けるEndPoint?
Single logout Service

Logout Request/Responseを受けるEndPoint?
Single logout Service

SAML Responseを受けるEndPoint?
Assertion Consumer Service

Termination

ManageIDNameRequest? (Termination) を受けるEndPoint?
Manage NameID Service

ManageIDNameRequest? (Affirmative) を受けるEndPoint?
？

↑

SAML XML構造と例 †

↑

SAMLコンポーネントとの関係 †

Transport Protocol

Transport Protocol ヘッダ
Transport Protocol ペイロード
- レスポンス（アサーション）
  - Authentication statements
  - Other statements

↑

Assertion、Subject、Statementの構造 †

単一のAuthentication statementを含むAssertionの例を含むXMLフラグメント

 1: <saml:Assertion
 2:   xmlns:saml="urn:oasis:names:tc:SAML:2.0:assertion"
 3:   Version="2.0" IssueInstant="2005-01-31T12:00:00Z">
 4:   <saml:Issuer Format=urn:oasis:names:SAML:2.0:nameid-format:entity>> ... Nature of the assertion.
 5:     http://idp.example.org
 6:   </saml:Issuer>
 7:   <saml:Subject> ... Subject of the assertion.
 8:     <saml:NameID
 9:       Format="urn:oasis:names:tc:SAML:1.1:nameid-format:emailAddress">
10:       j.doe@example.com
11:     </saml:NameID>
12:   </saml:Subject>
13:   <saml:Conditions ... Additional conditions of period.
14:     NotBefore="2005-01-31T12:00:00Z"
15:     NotOnOrAfter="2005-01-31T12:10:00Z">
16:   </saml:Conditions>
17:   <saml:AuthnStatement ... Authentication statement
18:     AuthnInstant="2005-01-31T12:00:00Z" SessionIndex="67775277772">
19:     <saml:AuthnContext>
20:       <saml:AuthnContextClassRef>
21:         urn:oasis:names:tc:SAML:2.0:ac:classes:PasswordProtectedTransport
22:       </saml:AuthnContextClassRef>
23:     </saml:AuthnContext>
24:   </saml:AuthnStatement>
25: </saml:Assertion>

NameIDのフォーマット
- Email address
- X.509 subject name
- Windows domain qualified name
- Kerberos principal name
- Entity identifier

Persistent identifier
- プライバシー保護仮名を使用する。
- 通常単一のSPでのみ使用するために確立される。
- 明示的に削除されるまでローカルIDと関連付けられたままになる。
- Name Identifier Mapping Protocolにより所属という概念に対するサポートも提供。

Transient identifier
- プライバシー保護仮名を使用する。
- IdPで作成された使い捨て識別子に対応するため、SPでの匿名性をサポート。
- SPで特定のローカルIDと関連付けられておらず、セッションが終了すると破棄される。

↑

Attribute statementsの構造 †

SAMLの属性構造は、特定のタイプの
- データストア
- データタイプ

が属性に使用されているとは想定していない。

注意

単一のステートメントに複数の属性を含めることができる。

属性名は、属性名を解釈するか名前形式で修飾される。

 1: <saml:AttributeStatement>
 2:   <saml:Attribute ... SAML X.500 / LDAP属性プロファイル
 3:     xmlns:x500="urn:oasis:names:tc:SAML:2.0:profiles:attribute:X500"
 4:     NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:uri"
 5:     Name="urn:oid:2.5.4.42" FriendlyName="givenName">
 6:     <saml:AttributeValue xsi:type="xs:string" x500:Encoding="LDAP">
 7:       John
 8:     </saml:AttributeValue>
 9:   </saml:Attribute>
10:   <saml:Attribute
11:     NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:basic"
12:     Name="LastName">
13:     <saml:AttributeValue xsi:type="xs:string">
14:       Doe
15:     </saml:AttributeValue>
16:   </saml:Attribute>
17:   <saml:Attribute
18:     NameFormat="http://smithco.com/attr-formats"
19:     Name="CreditLimit">
20:     xmlns:smithco="http://www.smithco.com/smithco-schema.xsd"
21:     <saml:AttributeValue xsi:type="smithco:type">
22:       <smithco:amount currency="USD">500.00</smithco:amount>
23:     </saml:AttributeValue>
24:   </saml:Attribute>
25: </saml:AttributeStatement>

↑

Message構造とSOAP Binding †

SAMLパーティがSOAP対応である環境では、
SOAP Bindingを使用してSAML要求/応答プロトコルメッセージを交換できる。

HTTP Response
- SOAP envlope
  - SOAP ヘッダ
  - SOAPボディ
    SAMLリクエスト
    or SAMLレスポンス

例

Attribute Query in SOAP Envelope

 1: <?xml version="1.0" encoding="UTF-8"?>
 2: <env:Envelope
 3:   xmlns:env="http://www.w3.org/2003/05/soap/envelope/">
 4:   <env:Body>
 5:     <samlp:AttributeQuery
 6:       xmlns:saml="urn:oasis:names:tc:SAML:2.0:assertion"
 7:       xmlns:samlp="urn:oasis:names:tc:SAML:2.0:protocol"
 8:       ID="aaf23196-1773-2113-474a-fe114412ab72"
 9:       Version="2.0" IssueInstant="2006-07-17T20:31:40Z">
10:       <saml:Issuer>
11:         http://example.sp.com
12:       </saml:Issuer>
13:       <saml:Subject>
14:         <saml:NameID
15:           Format="urn:oasis:names:tc:SAML:1.1:nameid-format:X509SubjectName">
16:           C=US, O=NCSA-TEST, OU=User, CN=trscavo@uiuc.edu
17:         </saml:NameID>
18:       </saml:Subject>
19:       <saml:Attribute
20:         NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:uri"
21:         Name="urn:oid:2.5.4.42" FriendlyName="givenName">
22:       </saml:Attribute>
23:     </samlp:AttributeQuery>
24:   </env:Body>
25: </env:Envelope>

Response in SOAP Envelope

 1: <?xml version="1.0" encoding="UTF-8"?>
 2: <env:Envelope xmlns:env="http://schemas.xmlsoap.org/soap/envelope/">
 3:   <env:Body>
 4:     <samlp:Response
 5:       xmlns:samlp="urn:oasis:names:tc:SAML:2.0:protocol"
 6:       xmlns:saml="urn:oasis:names:tc:SAML:2.0:assertion"
 7:       ID="i92f8b5230dc04d73e93095719d191915fdc67d5e"
 8:       Version="2.0" IssueInstant="2006-07-17T20:31:41Z"
 9:       InResponseTo="aaf23196-1773-2113-474a-fe114412ab72 "> ... 応答先の要求を参照
10:       <saml:Issuer>
11:         http://idp.example.org
12:       </saml:Issuer>
13:       <samlp:Status>
14:         <samlp:StatusCode Value="urn:oasis:names:tc:SAML:2.0:status:Success"/>
15:       </samlp:Status>
16:       ...SAML assertion...
17:     </samlp:Response>
18:   </env:Body>
19: </env:Envelope>

↑

プライバシー †

情報技術の文脈では、プライバシは一般に、

自分のIDデータがどのように共有され使用されるかを制御するユーザの能力
複数のSPでの彼らの行動が不適切に関連付けられるのを妨げるメカニズム

の両方を指す。

↑

ユーザの能力 †

IDデータの共有を制御するユーザの能力必要になる。
この同意がどのように、行われるかは、SAMLの範囲外。
SAMLは、IDデータの共有を制御するため、以下をサポートする。
- Authentication Contextにより十分な保証レベルでユーザを認証できる。
- 特定の操作に同意したユーザのクレームをプロバイダ間で表現する。

↑

メカニズム †

仮名の確立をサポート

↑

主要ProfileとFederationのUseCase? †

↑

Web Browser SSO Profile †

使用される可能性が高い典型的なフロー

↑

概要 †

主に2つのオプションがある。

1つ目はフローがSP開始またはIdP開始のどちらであるか

SP開始：SPで開始されるWeb SSOモデル
- ユーザはSPにログインしていないため、リソースへのアクセスを許可する前に、 SPはユーザをIdPに送信する。
- IdPでユーザを認証し、IdPは、アサーションを作成し、アサーションをSPに送り返す。
- SPは、アサーションを検証し、ユーザにリソースへのアクセスを許可するかどうかを決定。

IdP開始：IdPで開始されるWeb SSOモデル
- ユーザは既に認証されていて、IdP上のSPへのリンクをクリック。
- IdPはアサーションを作成し、、アサーションをSPに送信。
- SPは、アサーションを検証し、ユーザにリソースへのアクセスを許可するかどうかを決定。

2つ目はIdPとSP間のメッセージ配信に使用されるバインディング

Authentication Request message
- HTTP Redirect Binding
- HTTP POST Binding
- HTTP Artifact Binding

Authentication Response message
- HTTP POST Binding
- HTTP Artifact Binding

↑

SP-Initiated SSO: Redirect/POST Bindings †

SP-Initiated SSO

Authentication Request message
HTTP Redirect Bindingでリクエスト

HTTP Redirect

https://idp.example.org/SAML2/SSO/Redirect?SAMLRequest=request&RelayState=token

SAML Request

<samlp:AuthnRequest
  xmlns:samlp="urn:oasis:names:tc:SAML:2.0:protocol"
  xmlns:saml="urn:oasis:names:tc:SAML:2.0:assertion"
  ID="identifier_1" Version="2.0"
  IssueInstant="2004-12-05T09:21:59Z"
  AssertionConsumerServiceIndex="1">
  <saml:Issuer>
    https://sp.example.com/SAML2
  </saml:Issuer>
  <samlp:NameIDPolicy
    AllowCreate="true"
    Format="urn:oasis:names:tc:SAML:2.0:nameid-format:transient"/>
</samlp:AuthnRequest>

Authentication Response message
HTTP POST Bindingでレスポンス

HTML Form

<form method="post" action="https://sp.example.com/SAML2/SSO/POST" ...>
  <input type="hidden" name="SAMLResponse" value="response" />
  <input type="hidden" name="RelayState" value="token" />
  ...
  <input type="submit" value="Submit" />
</form>

HTTP POST

POST /SAML2/SSO/POST HTTP/1.1
Host: sp.example.com
Content-Type: application/x-www-form-urlencoded
Content-Length: nnn
SAMLResponse=response&RelayState=token

SAML Response

<samlp:Response
xmlns:samlp="urn:oasis:names:tc:SAML:2.0:protocol"
xmlns:saml="urn:oasis:names:tc:SAML:2.0:assertion"
ID="identifier_2" InResponseTo="identifier_1"
Version="2.0" IssueInstant="2004-12-05T09:22:05Z"
Destination="https://sp.example.com/SAML2/SSO/POST">
<saml:Issuer>
  https://idp.example.org/SAML2
</saml:Issuer>
<samlp:Status>
  <samlp:StatusCode
    Value="urn:oasis:names:tc:SAML:2.0:status:Success"/>
  </samlp:Status>
  <saml:Assertion
    xmlns:saml="urn:oasis:names:tc:SAML:2.0:assertion"
    ID="identifier_3" Version="2.0"
    IssueInstant="2004-12-05T09:22:05Z">
    <saml:Issuer>
      https://idp.example.org/SAML2
    </saml:Issuer>
    <!-- a POSTed assertion MUST be signed -->
    <ds:Signature xmlns:ds="http://www.w3.org/2000/09/xmldsig#">
      ...
    </ds:Signature>
    <saml:Subject>
      <saml:NameID Format="urn:oasis:names:tc:SAML:2.0:nameid-format:transient">
        3f7b3dcf-1674-4ecd-92c8-1544f346baf8
      </saml:NameID>
      <saml:SubjectConfirmation Method="urn:oasis:names:tc:SAML:2.0:cm:bearer">
        <saml:SubjectConfirmationData
        InResponseTo="identifier_1"
        Recipient="https://sp.example.com/SAML2/SSO/POST"
        NotOnOrAfter="2004-12-05T09:27:05Z"/>
      </saml:SubjectConfirmation>
    </saml:Subject>
    <saml:Conditions
      NotBefore="2004-12-05T09:17:05Z"
      NotOnOrAfter="2004-12-05T09:27:05Z">
      <saml:AudienceRestriction>
        <saml:Audience>
          https://sp.example.com/SAML2
        </saml:Audience>
      </saml:AudienceRestriction>
    </saml:Conditions>
    <saml:AuthnStatement
      AuthnInstant="2004-12-05T09:22:00Z"
      SessionIndex="identifier_3">
      <saml:AuthnContext>
        <saml:AuthnContextClassRef>
          urn:oasis:names:tc:SAML:2.0:ac:classes:PasswordProtectedTransport
        </saml:AuthnContextClassRef>
      </saml:AuthnContext>
    </saml:AuthnStatement>
  </saml:Assertion>
</samlp:Response>

その後
- SAML Responseのデジタル署名を検証
- 内容を処理し、SPでのローカルログオンセキュリティコンテキストを作成
- SPはRelayState?データによって、最初に要求されたリソースURLを呼び戻す。
- アクセス検査が行われ、検査に合格すると、リソースがブラウザに返される。

↑

SP-Initiated SSO: POST/Artifact Bindings †

SP-Initiated SSO

Authentication Request message
HTTP POST Bindingでリクエスト

HTML Form

<form method="post" action="https://idp.example.org/SAML2/SSO/POST" ...>
  <input type="hidden" name="SAMLRequest" value="request" />
  <input type="hidden" name="RelayState" value="token" />
  ...
  <input type="submit" value="Submit" />
</form>

HTTP POST

POST /SAML2/SSO/POST HTTP/1.1
Host: idp.example.org
Content-Type: application/x-www-form-urlencoded
Content-Length: nnn
SAMLRequest=request&RelayState=token

SAML Request
同上

Authentication Response message

HTTP Redirect Bindingでレスポンス

HTTP Redirect
Technical Overviewに記載なし。

SAML Response
同上

HTTP Artifact Bindingでアサーションを取得

Artifact Resolve

<samlp:ArtifactResolve
  xmlns:samlp="urn:oasis:names:tc:SAML:2.0:protocol"
  xmlns:saml="urn:oasis:names:tc:SAML:2.0:assertion"
  ID="identifier_2" Version="2.0" IssueInstant="2004-12-05T09:22:04Z"
  Destination="https://idp.example.org/SAML2/ArtifactResolution">
  <saml:Issuer>
    https://sp.example.com/SAML2
  </saml:Issuer>
  <!-- an ArtifactResolve message SHOULD be signed -->
  <ds:Signature xmlns:ds="http://www.w3.org/2000/09/xmldsig#">
    ...
  </ds:Signature>
  <samlp:Artifact>
    artifact
  </samlp:Artifact>
</samlp:ArtifactResolve>

Artifact Response

<samlp:ArtifactResponse
  xmlns:samlp="urn:oasis:names:tc:SAML:2.0:protocol"
  ID="identifier_3" InResponseTo="identifier_2"
  Version="2.0" IssueInstant="2004-12-05T09:22:05Z">
  <!-- an ArtifactResponse message SHOULD be signed -->
  <ds:Signature xmlns:ds="http://www.w3.org/2000/09/xmldsig#">
    ...
  </ds:Signature>
  <samlp:Status>
    <samlp:StatusCode Value="urn:oasis:names:tc:SAML:2.0:status:Success"/>
  </samlp:Status>
  <samlp:Response
    xmlns:samlp="urn:oasis:names:tc:SAML:2.0:protocol"
    xmlns:saml="urn:oasis:names:tc:SAML:2.0:assertion"
    ID="identifier_4" InResponseTo="identifier_1"
    Version="2.0" IssueInstant="2004-12-05T09:22:05Z"
    Destination="https://sp.example.com/SAML2/SSO/Artifact">
    <saml:Issuer>
      https://idp.example.org/SAML2
    </saml:Issuer>
    <ds:Signature xmlns:ds="http://www.w3.org/2000/09/xmldsig#">
      ...
    </ds:Signature>
    <samlp:Status>
      <samlp:StatusCode Value="urn:oasis:names:tc:SAML:2.0:status:Success"/>
    </samlp:Status>
    <saml:Assertion
      xmlns:saml="urn:oasis:names:tc:SAML:2.0:assertion"
      ID="identifier_5" Version="2.0"
      IssueInstant="2004-12-05T09:22:05Z">
      <saml:Issuer>
         https://idp.example.org/SAML2
      </saml:Issuer>
      <!-- a Subject element is required -->
      <saml:Subject>
        <saml:NameID
          Format="urn:oasis:names:tc:SAML:1.1:nameid-format:emailAddress">
          user@mail.example.org
        </saml:NameID>
        <saml:SubjectConfirmation
          Method="urn:oasis:names:tc:SAML:2.0:cm:bearer">
          <saml:SubjectConfirmationData
             InResponseTo="identifier_1"
             Recipient="https://sp.example.com/SAML2/SSO/Artifact"
             NotOnOrAfter="2004-12-05T09:27:05Z"/>
        </saml:SubjectConfirmation>
      </saml:Subject>
      <saml:Conditions
        NotBefore="2004-12-05T09:17:05Z"
        NotOnOrAfter="2004-12-05T09:27:05Z">
        <saml:AudienceRestriction>
          <saml:Audience>
            https://sp.example.com/SAML2
          </saml:Audience>
        </saml:AudienceRestriction>
      </saml:Conditions>
      <saml:AuthnStatement
        AuthnInstant="2004-12-05T09:22:00Z"
        SessionIndex="identifier_5">
        <saml:AuthnContext>
          <saml:AuthnContextClassRef>
            urn:oasis:names:tc:SAML:2.0:ac:classes:PasswordProtectedTransport
          </saml:AuthnContextClassRef>
        </saml:AuthnContext>
      </saml:AuthnStatement>
    </saml:Assertion>
  </samlp:Response>
</samlp:ArtifactResponse>

その後
- Artifact Responseのデジタル署名を検証
- 内容を処理し、SPでのローカルログオンセキュリティコンテキストを作成
- SPはRelayState?データによって、最初に要求されたリソースURLを呼び戻す。
- アクセス検査が行われ、検査に合格すると、リソースがブラウザに返される。

↑

IdP-Initiated SSO: POST Binding †

もともとSAML v1でサポートされていたIdP-Initiated SSOユースケースを引き続きサポート

Authentication Request message
N/A

Authentication Response message
HTTP POST Bindingでレスポンス（リクエストはないが）

↑

ECP Profile †

Enhanced Client and Proxy（ECP）プロファイル

↑

概要 †

特別な機能を持たない市販のブラウザで動作する、
- 拡張クライアントデバイス
- ゲートウェイ・プロキシ

を考慮に入れたプロファイル

※ 昔の携帯電話（ガラケー）など機能の貧弱なDEVICEを想定して
　作成された仕様であるため、昨今はあまり使われないと思う。

↑

ECP Profile Using PAOS Binding †

PAOS（Reverse SOAP）という単一のバインディングを定義

SOAPヘッダとSOAP本文を使用
SAML Request、ResponseをすべてSOAPで処理する。
これらの処理は、SP、IdP、ゲートウェイ・プロキシが協調して行う。

↑

Single Logout Profile †

↑

概要 †

SAMLのシングルログアウトのプロファイル
シングルログアウト ≒ Oneアクションで複数のSP & IdPからログアウト出来る的な。
1つのSPで開始され、IdPのSingle Logout Serviceから各SPのSingle Logout Serviceに要求が送信される。

↑

SP-Initiated Single Logout with Multiple SPs †

シングルログアウトのメッセージは以下のBindingを使用できる。

Synchronous？
- SOAP over HTTP binding

Asynchronous？
- HTTP Redirect bindings
- HTTP POST bindings
- HTTP Artifact bindings

Cookie認証チケットを削除する場合、ブラウザをSPにリダイレクトする必要がある。
- だったら、最初からHTTP Redirect bindingsを使えと言う気もするが、
- そもそも、SOAP over HTTP bindingの場合、どうやって処理するのか？

↑

Establishing and Managing Federated Identities †

Federated Identitiesを確立・管理するSAMLメカニズムの説明

↑

概要 †

フェデレーションスタイル

↑

Federation Using Out-of-Band Account Linking †

SAML1.0でサポートされている唯一のスタイル（SAML2.0でも引き続きサポート）。
SAML仕様の外でアカウント同期が行われる（Hybrid-IdP の Azure AD Connectみたいな）。

↑

Federation Using Persistent Pseudonym Identifiers †

IdPは、永続的なSAML名識別子を使用して、SPのローカルIDと関連付ける。
SAML2.0では、AuthnRequest?にNameIDPolicy要素を提供して、SPの動的動作を強制できる。

以下の様なスキーマになるらしい（linked IDで、SP / Idp間のlocal IDを紐付ける）
# SP1 IdP1
local ID IdP linked ID local ID SP linked ID
1 XXX IdP1 111 <-> AAA SP1 111

#	SP1		IdP1
1	XXX	IdP1	111	<->	AAA	SP1	111

（初回時）動的動作で、ユーザーは、
- SPでローカルの資格情報を提供するよう求められる。
- ２つのアカウントを統合したいかどうかを尋ねられる。

↑

Federation Using Transient Pseudonym Identifiers †

一時的な仮名識別子を使用して、SSOセッションの存続期間中にSPのローカルIDと関連付ける。

以下の様なスキーマになるらしい（SP側が一時的な仮名識別子を使用）
# SP1 IdP1
local ID IdP linked ID local ID SP linked ID
1 N/A IdP1 111 <-> AAA SP1 111

#	SP1		IdP1
1	N/A	IdP1	111	<->	AAA	SP1	111

連携される属性
- 基本、メンバーシップレベル属性のみで匿名ユーザとして処理できる。
- 必要に応じて、SAML属性クエリを属性機関に送信し、ユーザーID属性を取得できる。

↑

Federation Termination †

既存のフェデレーションの終了。

ManageIDNameRequest?(Termination)をIdPのManage NameID Serviceに送信する。
これにより、Federation Using Persistent Pseudonym Identifiersの関連付けを解除する。

↑

Use of Attributes †

SAMLアサーションによる、属性転送機能と、その属性の使い方。

↑

プロファイル情報の転送 †

IdPからSPへユーザプロファイル情報を伝達して使用する。

↑

属性に基づく承認 †

メンバーシップレベル属性のみで匿名ユーザとして処理できる。
IdPとSPは、属性名と値に関する事前の合意を必要とする。

↑

詳細 †

↑

SAML Profiles †

↑

SAML Bindings †

↑

SAML Core †

↑

SAML Protocols †

↑

SAML Assertions †

↑

SAML Signature or Encryption †

↑

構築と展開の2つの概念 †

↑

SAML Metadata †

↑

Authentication Context †

↑

SAMLを実装する。 †

↑

以下、参考 †

SAML認証に関する自分なりのまとめ
なんとな～くしあわせ？の日記
https://nantonaku-shiawase.hatenablog.com/entry/2016/07/13/081053

SAML Profiles ～ SSOだけじゃなく色んなシナリオあるって知ってた？～ - Qiita
https://qiita.com/samiii/items/6096723dfbebf049ec73

↑

OASIS †

OASISは「SGML Open」として1993年、

主に「研修活動を通じたSGMLの採用促進を目的として」結成された、

SGMLツール業者の業界団体。

↑

SAML 1.0 †

http://www.oasis-open.org/committees/download.php/2290/oasis-sstc-saml-1.0.zip

SAML 1.0（XML Security Assertion Markup Language）
http://www.oasis-open.org/committees/security/#documents

Assertions and Protocol［SAML Core］
http://www.oasis-open.org/committees/security/docs/cs-sstc-core-01.pdf

SAMLのAssertionsのスキーマと要求／応答プロトコルを定めた仕様

Bindings and Profiles［SAML Bind］
http://www.oasis-open.org/committees/security/docs/cs-sstc-bindings-01.pdf

SAMLをSOAPとHTTPにバインドする仕組みとSSOプロファイルの規定

Security and Privacy Considerations［SAML Sec］
http://www.oasis-open.org/committees/security/docs/cs-sstc-sec-consider-01.pdf

SAMLのセキュリティ要件を考察したもの

Conformance Program Specification［SAML Conform］
http://www.oasis-open.org/committees/security/docs/cs-sstc-conform-01.pdf

SAMLの相互運用性を確保するために適合性要件をまとめたもの

Glossary［SAML Gross］
http://www.oasis-open.org/committees/security/docs/cs-sstc-glossary-01.pdf

↑

SAML 1.1 †

http://www.oasis-open.org/committees/download.php/3400/oasis-sstc-saml-1.1-pdf-xsd.zip

↑

SAML 2.0 †

http://docs.oasis-open.org/security/saml/v2.0/saml-2.0-os.zip

Security Assertion Markup Language (SAML) V2.0 Technical Overview - OASIS
http://docs.oasis-open.org/security/saml/Post2.0/sstc-saml-tech-overview-2.0.html

以下を読むとイイらしい。
某Qiitaの記事を参考にすると、TechnicalOverview? をざっと眺めて、
どの Profile か選択してから Profile, binding, core と見ていくとイイらしい。

その他、ロードマップに含まれるもの。
- SAMLAuthnCxt?
  http://docs.oasis-open.org/security/saml/v2.0/saml-authn-context-2.0-os.pdf
- SAMLMeta
  http://docs.oasis-open.org/security/saml/v2.0/saml-metadata-2.0-os.pdf

↑

Reference †

↑

用語集 †

SAML仕様全体を通して使用される用語を規範的に定義
可能な限り、用語は他のセキュリティ用語集で定義されている用語と一致させてある。

SAMLGloss
http://docs.oasis-open.org/security/saml/v2.0/saml-glossary-2.0-os.pdf

↑

適合要件 †

SAMLConform
http://docs.oasis-open.org/security/saml/v2.0/saml-conformance-2.0-os.pdf

↑

セキュリティとプライバシーに関する考慮事項 †

SAMLのセキュリティとプライバシーの特性について分析/説明。

SAMLSec
http://docs.oasis-open.org/security/saml/v2.0/saml-sec-consider-2.0-os.pdf

↑

Security †

http://www.oasis-open.org/committees/security/.

SAMLExecOvr?
- エグゼクティブの概要
- SAMLとその主な利点についてエグゼクティブレベルで簡単に説明（非規範的な文書）。

SAMLMDV1x
SAML V1.x OASIS規格をサポートするSAMLエンティティ
を記述するためのSAML V2.0メタデータ構成体の使用

SAMLMDExtQ
クエリ要求者用のSAMLメタデータ拡張

SAMLProt3P
- サードパーティの要求に対するSAMLプロトコルの拡張を定義
- SAMLプロトコルの拡張意図された応答受信者以外のエンティティによる要求を容易にするため

SAMLX509Attr
X.509認証ベースシステム用のSAML属性共有プロファイル

SAMLXPathAttr?
属性名としてXPath URIを使用するためのSAML属性の使用をプロファイル

SAMLErrata
- 正誤表
- SAML準拠ソフトウェアの実装者によって使用される可能性のある解釈へのガイド
- SAML V2.0規格の矛盾や不明確である点の解釈を明確化する。

↑

WSS †

http://www.oasis-open.org/committees/wss/

WSS
Web Services Security: SOAP Message Security 1.1 (WS-Security 2004).

WSSSAML
Web Services Security: SAML Token Profile 1.1. OASIS WSS-TC, February 2006.

↑

XML(W3C) †

XMLSig
XML署名の構文と処理
http://www.w3.org/TR/xmldsig-core/

XMLEnc
XML暗号化の構文と処理
http://www.w3.org/TR/2002/REC-xmlenc-core-20021210/

↑

Else †

ShibReqs?
Shibbolethの概要と要件
http://shibboleth.internet2.edu/docs/draft-internet2-shibboleth-requirements-01.html

XACML
OASIS拡張アクセス制御マークアップ言語（XACML）バージョン2.0
http://www.oasis-open.org/committees/xacml

↑

参考 †

OASIS | Advancing open standards for the information society
https://www.oasis-open.org/

OASIS (組織) - Wikipedia
https://ja.wikipedia.org/wiki/OASIS_(%E7%B5%84%E7%B9%94)

↑

SAML XML.org †

SAML 公式サイト

Online community for the SAML OASIS Standard
http://saml.xml.org/

SAML Specifications
http://saml.xml.org/saml-specifications

SAML Open Source Implementations
http://saml.xml.org/wiki/saml-open-source-implementations

↑

医療分野共通認証基盤整備コンソーシアム †

SAML 実装仕様書第 1.0 版
https://www.keieiken.co.jp/medit/pdf/240423/7-data.pdf
- 第Ⅰ編概要、用語及び参考文献
- 第Ⅱ編フレームワーク（SAML）
- 第Ⅲ編機能仕様
- 第Ⅳ編実装規約
- 第Ⅴ編試験仕様
- 第Ⅵ編セキュリティとプライバシに関する考慮事項

↑

用語 †

#	用語	説明
1	Principal プリンシパル	ID が認証可能なSystem Entity（通常は、ユーザ）。
2	Subject 主体	SAMLアサーションに含まれるプリンシパル
3	Profile プロファイル	いくつかの目的のひとつのルールの集合。
4	System Entity システムエンティティ	コンピュータ/ネットワークシステムのアクティブな要素。
5	Provider プロバイダ	IdPとSPの総称（System Entity）。
6	Identity Provider(IdP) アイデンティティプロバイダ	プリンシパルの ID 情報を作成、維持、及び管理し、他のサービスプロバイダに契約の範囲でプリンシパルの認証を提供するプロバイダ。
7	Service Provider(SP) サービスプロバイダ	プリンシパルまたは他のSystem Entityにサービスを提供するプロバイダ。
8	Attribute Assertion 属性アサーション	Subjectの属性に関する情報を伝えるAssertion。
9	Authentication Assertion 認証アサーション	Subjectに対して行われた認証に関する情報を伝達するアサーション。
10	Authorization Decision Assertion 認可決定アサーション	Subjectに対して決定された認可に関する情報を伝達するアサーション。
11	Security Assertion セキュリティアサーション	セキュリティアーキテクチャのコンテキストで精査されたアサーション。
12	SAML Authority SAML オーソリティ	Assertionを発行する抽象的なSystem Entity。
13	Attribute Authority 属性オーソリティ	属性アサーションを生成するSystem Entity。
14	Authentication Authority 認証オーソリティ	認証アサーションを生成するSystem Entity。
15	Session Authority セッションオーソリティ	セッションに関連する状態を保持しているSystem Entityの役割≒IdP。
16	Party 当事者	1つ以上の不特定のプリンシパル。
17	Asserting Party アサーティングパーティ	形式的には、一つ以上の SAML オーソリティをホストする管理ドメイン。非公式には、そのインスタンス。
18	Relying Party(RP) 当事者	別のSystem Entityからの情報に基づいて動作が決まるSystem Entity。
19	Policy Enforcement Point(PEP) ポリシー実行点	PDP に認可決定要求を送信し、応答で送信される認可決定アサーションを受け付ける。
20	Policy Decision Point(PDP) ポリシー決定点	PEP から認可決定要求を受け付けて、応答の認可決定アサーションを生成する。
21	SAML Requestor SAMLリクエスタ	サービス要求のために SAML プロトコルを利用するSystem Entity
22	SAML Responder SAMLレスポンダ	サービス要求に応答するために SAML プロトコルを利用するSystem Entity
23	SAML Artifact SAMLアーティファクト	固定サイズの構造化されたデータオブジェクトで間接参照して SAML プロトコルメッセージを取得する
24	Front Channel フロントチャンネル	UAなどの仲介者を経由するエンドポイント
25	Back Channel バックチャネル	UAなどの仲介者を経由しないエンドポイント

↑

機能概要 †

ユーザはUA（ブラウザ）を使用して、SP に対してリソース要求を送信する。

SP は、認証されていないユーザからのリソース要求の場合、
SP に対する<AuthnReq?>のRedirect要求をユーザのUAに返却する。

ユーザのUAは、SSLで IdPにRedirect要求の<AuthnReq?>を転送。

IdP は、ユーザを認証して認証アサーションを作成、
認証アサーションのArtifactのRedirect要求をユーザのUAに返却する。

ユーザのUAは、Redirect要求のArtifactを SP に転送する。

SP は、IdP に対して<ArtifactResolve?>でArtifactを提示して認証アサーションを要求。

IdP は、SP に対して<ArtifactResponse?>で認証アサーションを応答する。

↑

通信フローの概要 †

↑

OSSTech †

↑

OpenSSO社内勉強会第二回 - SAML - †

https://www.osstech.co.jp/_media/techinfo/opensso/osstech-opensso-study-02-saml.pdf

↑

概要 †

SAMLとは
- 認証情報の送受信の方法を規定する
  - フォーマット（XML）
  - 通信プロトコル

仕様の原文
http://www.oasis-open.org/specs/index.php から入手可能
- saml-core-2.0-os.pdf
- saml-bindings-2.0-os.pdf
- saml-profiles-2.0-os.pdf
- saml-authn-context-2.0-os.pdf
- saml-metadata-2.0-os.pdf
- saml-conformance-2.0-os.pdf
- saml-sec-consider-2.0-os.pdf
- saml-glossary-2.0-os.pdf

SSO実現のための準備
信頼の輪（Circle of Trust - Cot）の準備
- CoT内のSPに対してのみSSO可能
- IdP-SP間でお互いを事前に登録（CoTを構成）
- 一つのCoT内に複数のIdPが存在することもある

アカウント連携

NameIDというユーザ識別子をIdPとSP間で共有
IdPのアカウントとSPのアカウントを紐付ける

NameIDには以下のものが使用される
- メールアドレス
- ユーザー名
- ユーザID（GUIDなどの識別子）
- 仮名：ランダムな文字列によるユーザ識別
- X.509のSubject

アカウント・ライフサイクル
サインイン・サインアウト < 連携・解除 < 作成・削除

SSOの開始
- CoTの構成・アカウント連携が完了して、SSO可能に
- OpenID Connect の Authorization Code Flow の Tokenリクエストが無い感じ。

↑

詳細 †

SAMLの構成要素

アサーション
IdPが発行するXML形式のユーザに関する証明情報

<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>

バインディング
- メッセージを既存の通信プロトコルに埋め込む方法を規定

IdP-SP間の通信有無で分類すると...。

無：HTTP Redirect、HTTP POST
OAuth 2.0 Form Post Response Mode みたいな
（SAMLでは、RequestとResponseの両方に適用されるのがポイント）

有：HTTP Artifact
アサーションがクライアントに渡ることがない、
OpenID Connect の Authorization Code Flow の code みたいな
ただ、SAML Responseだけでなく、SAML Requestにも使えるので、その辺りが異なる。

メタデータ

CoTの構成、アカウント連携に必要な情報
これによりIdP、SPの構築作業が楽になる

Google Apps のメタデータの例

<EntityDescriptor entityID="google.com" xmlns="urn:oasis:names:tc:SAML:2.0:metadata">
 <SPSSODescriptor protocolSupportEnumeration="urn:oasis:names:tc:SAML:2.0:protocol">
 <NameIDFormat>urn:oasis:names:tc:SAML:1.1:nameid-format:unspecified</NameIDFormat>
 <AssertionConsumerService index="1"
Binding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST"
 Location="https://www.google.com/a/ドメイン名/acs" />
 </SPSSODescriptor>
</EntityDescriptor>

↑

クラウド時代のシングルサインオン †

https://www.osstech.co.jp/_media/techinfo/seminar/hbstudy-20110416-sso.pdf

↑

概要 †

SAML : Secure Assertion Markup Lauguage
認証、認可、ユーザ属性情報などをXMLで送受信するための仕様
Webアプリの”認証処理”を、外部で代行してもらうための仕組み。

↑

用語 †

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

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

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

アカウント連携

↑

シーケンス †

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

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

メッセージの送受信方法

HTTP Redirect / HTTP POST Binding
- IdP-SP間の直接的な通信が発生しない
- ブラウザが通信を中継する（HTTP Redirect/HTTP POST を利用）

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

リソース・アクセス
リソースが格納されているuriを格納したRelayState?パラメタを使用してリダイレクトする。

↑

アサーション †

事前に 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>

↑

ネットワーク構成 †

IdPを社内LANに設置
SPへのアクセスを社内のみからに制限することが可能

IdPをDMZに設置
社外からSPにアクセスすることが可能

↑

OpenAMのSAML利用時の認証方式の指定について †

https://www.osstech.co.jp/_media/techinfo/openam/saml_authncontext_20150417.pdf

↑

認証方式の指定 †

<AuthnContextClassRef?>を使用する。

SPで、利用するIdPに認証方式を指定する。

SAML RequestのRequestedAuthnContex?を使用して指定する。

RequestedAuthnContex?は省略可能（多くのSPで使用していない）

SPはIdPに対してAuthentication Contextを通知できる。

<samlp:AuthnRequest
  xmlns:samlp="urn:oasis:names:tc:SAML:2.0:protocol"
  ID="XXXX" Version="2.0" IssueInstant="2015-04-13T04:59:38Z"
  Destination="xxxxxx" ForceAuthn="false" IsPassive="false"
  ProtocolBinding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST"
  AssertionConsumerServiceURL="XXXXX">
  <samlp:RequestedAuthnContext
    xmlns:samlp="urn:oasis:names:tc:SAML:2.0:protocol" Comparison="exact">
    <saml:AuthnContextClassRef xmlns:saml="urn:oasis:names:tc:SAML:2.0:assertion">
      urn:oasis:names:tc:SAML:2.0:ac:classes:PasswordProtectedTransport
    </saml:AuthnContextClassRef>
  </samlp:RequestedAuthnContext>
</samlp:AuthnRequest>

RequestedAuthnContext?の構成

<AuthnContextClassRef?>要素
Authentication Context Classを一つ以上記述

Comparison属性
Authentication Context Classの比較手法を指定
（exact（既定値）、minimum、maximum、better）

IdPで、SPに実施した認証方式に応答する。
- これにより、SPは、IdPでどのような認証が行われたか判断できる。
- SAML ResponseのAssertionには必須(MUST)の要素
```
AuthnStatement -> AuthnContext -> AuthnContextClassRef
```

↑

OpenAMの実装を把握する †

OpenAMをSPとして構築した場合

SAML RequestのRequestedAuthnContex?にAuthentication Context Classを指定可能
- 既定値では、PasswordProtectedTransport?を指定。
- QueryString?でAuthnContextClassRef?を指定することもできる。
- 「|」(パイプ)で区切ることで複数の<AuthnContextClassRef?>を指定することが可能

SAML ResponseとSAML RequestののAuthentication Context Classを比較
- 指定したAuthentication Context Classとマッチしなかった場合はエラー
- デフォルト設定ではPasswordProtectedTransport? のみ許容。
- 許容しないAuthentication Context Classの場合も同様のエラー

OpenAMをIdPとして構築した場合

SAML RequestのAuthentication Context Classを、
- 既定値は、PasswordProtectedTransport?として解釈。
- デフォルト設定ではPasswordProtectedTransport? のみ許容
- 許容しない値の場合はエラー

SAML ResponseのAuthentication Context Classは、
Assertion -> AuthnStatement? -> AuthnContext? -> AuthnContextClassRef?に指定される。

↑

Cybozu †

↑

サイボウズエンジニアのブログ †

SAML認証ができるまで - Cybozu Inside Out
http://developer.cybozu.co.jp/tech/?p=4224

SAMLはSecurity Assertion Markup Languageの略で、OASIS3によって策定された、
異なるセキュリティドメイン間で、認証情報を連携するためのXMLベースの標準仕様。

↑

用語 †

認証情報を提供する側を、Identity Provider（IdP）
認証情報を利用する側を、Service Provider（SP）

↑

仕様 †

Core
認証情報を表すXMLのスキーマ（Assertions）と、
メッセージ交換のプロトコル（Protocols）を定義。

Bindings
メッセージを実際の通信プロトコル（HTTPなど）にマッピングする方法を定義。

Profiles
特定のユースケースを実現するための組み合わせ方を定義。
- Assertions
- Protocols
- Bindings

Metadata
IdPやSPに関する情報を表現するためのXMLのスキーマを定義（IdPとSPの信頼関係を構築）。

↑

シーケンス †

Web Browser SSO Profileのシーケンス

ユーザーがSPにアクセスする
ユーザーが未ログイン状態な場合、SPが認証要求メッセージを生成する
ユーザーがSPから認証要求メッセージを受け取り、それをIdPに送る
IdPが認証要求メッセージを受け取り、ユーザーを認証する
IdPが認証応答メッセージを作成する
ユーザーがIdPから認証応答メッセージを受け取り、それをSPに送る
SPが認証応答メッセージを受け取り、検証する
メッセージの内容に問題がない場合、ユーザーはSPにログインできる

↑

要件 †

Web Browser SSO Profileの要件

IdPとの信頼関係の構築機能の設計

SPに信頼するIdPを登録する。
- IdPが認証要求メッセージを受け取るURL
- IdPが認証応答メッセージの署名の検証に使用する公開鍵
- SPからログアウトした後に遷移するURL
  （IdPのログアウト用URLへのリダイレクト）

IdPが信頼するSPの登録
IdPの管理画面で手動で設定するか、SPが提供するメタデータを読み込む。

管理画面で手動で設定
NameIDFormat要素、AssertionConsumerService?要素に相当する情報

SPが提供するメタデータを読み込む

<md:EntityDescriptor entityID="https://(sub_domain).cybozu.com">
  <md:SPSSODescriptor protocolSupportEnumeration="urn:oasis:names:tc:SAML:2.0:protocol">
    <md:NameIDFormat>
      urn:oasis:names:tc:SAML:1.1:nameid-format:unspecified
    </md:NameIDFormat>
    <md:AssertionConsumerService Binding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST" Location="https://(sub_domain).cybozu.com/saml/acs" index="0"/>
  </md:SPSSODescriptor>
</md:EntityDescriptor>

メッセージ処理機能の設計

認証要求メッセージの作成

認証要求メッセージをIdPに送る
- HTTP Redirect Binding :
  Deflateエンコード -> Base64エンコード -> URLエンコード
- HTTP POST Binding :
  Base64エンコード -> URLエンコード

IdPが発行した認証応答メッセージを受け取る
- HTTP Redirect Binding :
  Deflateエンコード -> Base64エンコード -> URLエンコード
- HTTP POST Binding :
  Base64エンコード -> URLエンコード

認証応答メッセージを検証する
- Version属性の評価
- <Status>要素の評価
- <SubjectConfirmation?>要素のmethod属性の評価
- <SubjectConfirmationData?>要素の内容の評価
- <Conditions>要素の評価
- <AudienceRestriction?>要素の評価
- <Assertion>要素の署名の検証

↑

cybozu.com ヘルプ †

SAML認証を使用したシングルサインオンを設定する
https://jp.cybozu.help/general/ja/admin/list_externalservices/list_saml/saml_settings.html

↑

SP Initiated な Web Browser SSO Profile †

SAMLリクエストとSAMLレスポンスには、次のバインディングを使用する。

SAMLリクエスト：HTTP Redirect Binding
SAMLレスポンス：HTTP POST Binding

↑

フロー †

ユーザがSPにアクセスする。

SPがSAMLリクエストを生成する。

ユーザがSPからSAMLリクエストを受け取る。

IdPがユーザを認証する。

IdPがSAMLレスポンスを生成する。

ユーザがIdPからSAMLレスポンスを受け取る。

SPがSAMLレスポンスを受け取り、検証する。

SAMLレスポンスの内容に問題がない場合、
ユーザがSPにログインした状態になる。

↑

設定 †

IdPにSPを登録する

手入力する場合。

エンティティID URLの最後に"/"（スラッシュ）をつけないでください。

SPのエンドポイントURL

ユーザーを識別する要素：NameID

メタデータファイルを使用する場合。
...。

SPにIdPを登録する

SPでSAML認証を有効化し、

SPにIdPの情報を設定。
- IdPのSSOエンドポイントURL（HTTP-Redirect）
- SPからのログアウト後に遷移するIdPのURL
- IdPが署名に使用する公開鍵の証明書

↑

Wikipedia †

↑

en †

Security Assertion Markup Language
https://en.wikipedia.org/wiki/Security_Assertion_Markup_Language

SAML 1.1
https://en.wikipedia.org/wiki/SAML_1.1

SAML 2.0
https://en.wikipedia.org/wiki/SAML_2.0

SAML Metadata
https://en.wikipedia.org/wiki/SAML_Metadata

↑

ja †

Security Assertion Markup Language
https://ja.wikipedia.org/wiki/Security_Assertion_Markup_Language

Tags: :IT国際標準, :認証基盤, :クレームベース認証, :SAML

#	SP1				IdP1
#	local ID	IdP	linked ID		local ID	SP	linked ID
1	XXX	IdP1	111	<->	AAA	SP1	111

SAMLの仕様を読む。 のバックアップ(No.25)

目次 †

概要 †

ロードマップ †

Technical Overview †

Core (Assertions and Protocols) †

XML Signature Syntax and Processing †

ユースケース †

参加者 †

Web-SSO †

IDフェデレーション †

アカウントリンク †

アーキテクチャ †

基本概念 †

基本的なSAMLの概念 †

構築と展開の2つの概念 †

高度な概念 †

SAML Components †

EndPoint? †

SAML XML構造と例 †

SAMLコンポーネントとの関係 †

Assertion、Subject、Statementの構造 †

Attribute statementsの構造 †

Message構造とSOAP Binding †

プライバシー †

ユーザの能力 †

メカニズム †

セキュリティ †

公開鍵基盤（PKI）に依存する信頼関係を推奨 †

HTTP over SSL 3.0またはTLS 1.0を推奨 †

主要ProfileとFederationのUseCase? †

Web Browser SSO Profile †

概要 †

SP-Initiated SSO: Redirect/POST Bindings †

SP-Initiated SSO: POST/Artifact Bindings †

IdP-Initiated SSO: POST Binding †

ECP Profile †

概要 †

ECP Profile Using PAOS Binding †

Single Logout Profile †

概要 †

SP-Initiated Single Logout with Multiple SPs †

Establishing and Managing Federated Identities †

概要 †

Federation Using Out-of-Band Account Linking †

Federation Using Persistent Pseudonym Identifiers †

Federation Using Transient Pseudonym Identifiers †

Federation Termination †

Use of Attributes †

プロファイル情報の転送 †

属性に基づく承認 †

詳細 †

構築と展開の2つの概念 †

以下、参考 †

OASIS †

SAML 1.0 †

SAML 1.1 †

SAML 2.0 †

Reference †

用語集 †

適合要件 †

セキュリティとプライバシーに関する考慮事項 †

Security †

WSS †

XML(W3C) †

Else †

参考 †

SAML XML.org †

医療分野共通認証基盤整備コンソーシアム †

用語 †

機能概要 †

OSSTech †

OpenSSO社内勉強会第二回 - SAML - †

概要 †

詳細 †

クラウド時代の シングルサインオン †

概要 †

用語 †

シーケンス †

アサーション †

クラウド時代のシングルサインオン †