1.1 の

セキュリティ アサーション マークアップ言語(SAML) は、セキュリティ ドメイン間で認証および承認データを交換するためのXML標準です。SA​​ML は、OASIS (組織)セキュリティ サービス技術委員会 の製品です。

SAML 1.1 は2003 年 9 月に OASIS 標準として承認されました。SAML 1.1 の重要な側面は、公式ドキュメント SAMLCore ^[1]および SAMLBind ^[2]で詳細に説明されています 。SAML を初めて使用する場合は、まずSAML入門トピックを読み、次に OASIS の SAMLOverview ^[3]ドキュメントを読むことをお勧めします。

SAML 1.1 より前、SAML 1.0 は2002 年 11 月に OASIS 標準として採用されました。SAML は、V1.0 以降、1 回のマイナー リビジョン (V1.1) と 1 回のメジャー リビジョン (V2.0) を経ています。V1.0 自体は比較的シンプルなプロトコルです。しかし、SAML 1.0 は歴史的な関心以上のもので、米国連邦電子認証イニシアチブが SAML 1.0 をその中核技術として採用しています。

SAMLのバージョン1.0と1.1は似ています。2つの標準の具体的な違いについてはSAMLDiff ^[4]を参照してください。この記事では、他の多くの標準や実装が依存する重要な標準であるSAML 1.1に焦点を当てています。

警告:実装者および展開者は、この記事のすべてのコード例は非規範的であり、説明のみを目的としていることに十分注意してください。規範的な要件については、OASIS SAML 仕様を参照してください。

SAMLアサーションには、サービス プロバイダーがアクセス制御の決定を行うために使用するステートメントが含まれています。たとえば、認証ステートメントは、プリンシパルが特定の時間に特定の認証方法を使用して ID プロバイダーで実際に認証したことをサービス プロバイダーにアサートします。プリンシパルに関するその他の情報は、認証ステートメントで公開される場合があります。たとえば、次の認証ステートメントでは、プリンシパルの電子メール アドレスがサービス プロバイダーにアサートされています。

  <saml:Assertion 
xmlns:saml= "urn:oasis:names:tc:SAML:1.0:assertion" MajorVersion= "1" MinorVersion= "1" AssertionID= "buGxcG4gILg5NlocyLccDz6iXrUa" Issuer= "https://idp.example.org/saml" IssueInstant= "2002-06-19T17:05:37.795Z" > <saml:Conditions NotBefore= "2002-06-19T17:00:37.795Z" NotOnOrAfter= "2002-06-19T17:10:37.795Z" /> <saml:AuthenticationStatement AuthenticationMethod= "urn:oasis:names:tc:SAML:1.0:am:password" AuthenticationInstant= "2002-06-19T17:05:17.706Z" > <saml:Subject> <saml:NameIdentifier Format= "urn:oasis:names:tc:SAML:1.1:nameid-format:emailAddress" > user@idp.example.org
 </saml:NameIdentifier> <saml:SubjectConfirmation> <saml:ConfirmationMethod> urn:oasis:names:tc:SAML:1.0:cm:bearer
 </saml:ConfirmationMethod> </saml:SubjectConfirmation> </saml:Subject> </saml:AuthenticationStatement> </saml:Assertion>    
     
    
    
    
    
      
      
    
      
      
      
        
          
                  
        
          
                      
        
      
    
  

多くの場合、電子メール アドレス (上記の例のように) で十分です。ただし、サービス プロバイダーがアクセス制御の決定を下す前に、追加の情報が必要になる場合があります。例として、学生が奨学金データにアクセスできるとします。属性ステートメントは、プリンシパルが「学生」の所属を持っているかどうかを示します。サービス プロバイダーは、これを使用して奨学金アプリケーションへのアクセスを許可または拒否します。

  <saml:Assertion 
xmlns:saml= "urn:oasis:names:tc:SAML:1.0:assertion" MajorVersion= "1" MinorVersion= "1" Issuer= "https://idp.example.org/saml" ... > <saml:Conditions NotBefore= "..." NotAfter= "..." /> <saml:AuthenticationStatement AuthenticationMethod= "..." AuthenticationInstant= "..." > <saml:Subject> ... </saml:Subject> </saml:AuthenticationStatement> <saml:AttributeStatement> <saml:Subject> ... </saml:Subject> <saml:Attribute AttributeName= "urn:mace:dir:attribute-def:eduPersonAffiliation" AttributeNamespace= "urn:mace:shibboleth:1.0:attributeNamespace:uri" > <saml:AttributeValue>メンバー</saml:AttributeValue> <saml:AttributeValue>学生</saml:AttributeValue> </saml:Attribute> </saml:AttributeStatement> </saml:Assertion>    
     
     
      
    
      
      
      
    
    
      
      
        
        
        
        
      
    
  

属性は多くの場合LDAPディレクトリから取得されるため、セキュリティ ドメイン間で一貫した属性表現が重要です。

学生が奨学金申請書にアクセスする方法を示した上記の例では、サービス プロバイダーはポリシー適用ポイントとポリシー決定ポイントの両方として機能しています。状況によっては、ポリシー決定ポイントを ID プロバイダーに関連付ける方が望ましい場合があります。この場合、サービス プロバイダーは ID プロバイダーに URI を渡し、ID プロバイダーは、プリンシパルが特定の URI の保護されたリソースにアクセスできるようにするかどうかを決定する承認決定ステートメントをアサートします。

  <saml:Assertion 
xmlns:saml= "urn:oasis:names:tc:SAML:1.0:assertion" MajorVersion= "1" MinorVersion= "1" Issuer= "https://idp.example.org/saml" ... > <saml:Conditions ... /> <saml:AuthorizationDecisionStatement Decision= "Permit" Resource= "https://sp.example.com/confidential_report.html" > <saml:Subject> ... </saml:Subject> <saml:Action>読み取り</saml:Action> </saml:AuthorizationDecisionStatement> </saml:Assertion>    
     
     
     
    
      
      
      
      
    
  

3 つのステートメント タイプは相互に排他的ではありません。たとえば、認証ステートメントと属性ステートメントの両方を 1 つのアサーションに含めることができます (上記を参照)。これにより、サービス プロバイダーと ID プロバイダー間で後続のラウンド トリップを行う必要がなくなります。

SAMLプロトコルは、シンプルな要求応答プロトコルです。SA​​ML 要求者は、Request応答者に SAML 要素を送信します。

  <samlp:Request 
xmlns:samlp= "urn:oasis:names:tc:SAML:1.0:protocol" MajorVersion= "1" MinorVersion= "1" RequestID= "aaf23196-1773-2113-474a-fe114412ab72" IssueInstant= "2006-07-17T22:26:40Z" > <!-- ここに他の SAML 要素を挿入します --> </samlp:Request>    
     
    
    
    
  

同様に、SAML レスポンダーはResponseリクエスターに SAML 要素を返します。

  <samlp:Response 
xmlns:samlp= "urn:oasis:names:tc:SAML:1.0:protocol" MajorVersion= "1" MinorVersion= "1" ResponseID= "b07b804c-7c29-ea16-7300-4f3d6f7928ac" InResponseTo= "aaf23196-1773-2113-474a-fe114412ab72" IssueInstant= "2006-07-17T22:26:41Z" > <!-- アサーションを含むその他の SAML 要素をここに挿入します --> </samlp:Response>    
     
    
    
    
    
  

このメッセージ交換に影響を与えるために必要なバインディングとプロファイルについては、次のセクションで詳しく説明します。

SAML 1.1 では、正式には SAML SOAP バインディングという 1 つのプロトコルバインディングのみが定義されています。互換性のある SAML 1.1 実装では、SAML over SOAP over HTTP (同期プロトコル バインディング) を実装する必要があります。SAML SOAP バインディングのプロトコルに依存しない側面が遵守されている限り、HTTP 以外のトランスポート メカニズムも使用できます (SAMLBind ^[2]のセクション 3.1.2 を参照)。

SAML 1.1 SOAP バインディングは、 SOAPバージョン 1.1 上に構築されています(番号はまったくの偶然です)。SAML リクエスターは、RequestSOAP メッセージの本文内に SAML 要素をラップします。同様に、SAML レスポンダーは、Response返された SOAP メッセージの本文内に SAML 要素を返します。エラーがある場合、レスポンダーは代わりに SOAP エラー コードを返します。

すべての SAML マークアップは、SOAP 本文に含める必要があります。SAML 1.1 では、SAML 固有の SOAP ヘッダーは定義されていません。リクエスタは、任意の SOAP ヘッダーを自由に挿入できます (ただし、必須ではありません)。

SOAP 1.1 では、SOAPAction各 HTTP リクエストに HTTP ヘッダーを含める必要があることを思い出してください (ただし、その値は空でもかまいません)。SAML 要求者は、ヘッダーに次の値を指定できますSOAPAction。

SOAP アクション: http://www.oasis-open.org/committees/security

ただし、SAML レスポンダーはこの値に依存してはなりません。

SAML 要求と応答には安全な接続は必要ありませんが、メッセージの整合性と機密性が必要な状況では、サーバー側証明書を使用した HTTP over SSL 3.0 または TLS 1.0 が必要です。

SAML レスポンダは、SAML リクエスタへの応答を拒否する場合、「403 Forbidden」応答を返すことがあります。レスポンダは、SOAP エラーが発生した場合、「500 Internal Server Error」応答を返す必要があります (SOAP 障害要素も含める必要があります)。それ以外の場合は、SAML 処理エラーが発生しても、「200 OK」応答が返されます。このような応答には、StatusSOAP 本文に SAML 要素が含まれます。

一般に、プロファイルは、最終的にアイデンティティ プロバイダーからサービス プロバイダーにアサーションを転送するために必要なユース ケースとメッセージ交換を記述します。SAML 1.1 では、次の 2 つの Web ブラウザー SSO プロファイルが指定されています。

1. ブラウザ/POSTプロファイル
2. ブラウザ/アーティファクト プロファイル

ブラウザ/POST プロファイルは、HTTP POST を使用してブラウザを通じて SSO アサーションを値で渡す「プッシュ」操作に依存します。アイデンティティ プロバイダーがアサーションをサービス プロバイダーに「プッシュ」すると言います。

ブラウザ/アーティファクト プロファイルは、「プル」メカニズムを採用しています。プロファイルは基本的に、参照によってID プロバイダからサービス プロバイダに SSO アサーションを渡し(HTTP リダイレクトを使用するブラウザ経由)、その後バックチャネル交換によって逆参照されます (つまり、サービス プロバイダは SAML over SOAP over HTTP を使用して ID プロバイダからアサーションを「プル」します)。

これらのプロファイルは、クロスドメイン シングル サインオン (SSO) をサポートします。仕様では追加のプロファイルは定義されていません。特に、SAML 1.1 では、Web サービス メッセージをセキュリティで保護するプロファイルも、シングル ログアウト プロファイルもサポートされていません。

SAML 1.1 プロファイルは両方とも、アイデンティティ プロバイダーによって管理されるサイト間転送サービスから始まります。プリンシパルが転送サービスに最初に到達する方法は、仕様では規定されていません。考えられるシナリオについては、SAMLOverview ^[3]のセクション 4.1 および 4.2 を参照してください。実際には、サービス プロバイダーのセキュリティ保護されたリソースにアクセスするクライアントは、アイデンティティ プロバイダーのサイト間転送サービスにリダイレクトされますが、これを達成するために必要な手順の正確なシーケンスは SAML 1.1 では概説されていません。(これに関する大まかなアイデアについては、SAMLOverview ^[3]のセクション 4.3 を参照してください。) このシナリオは、SAML 2.0 で徹底的に対処されています。

サイト間転送サービスにアクセスした後、プリンシパルはサービス プロバイダーのアサーション コンシューマー サービスに転送されます。サイト間転送サービスからアサーション コンシューマー サービスにプリンシパルが転送される方法は、使用するプロファイルによって異なります。ブラウザー/アーティファクト プロファイルの場合はリダイレクトが使用されます。ブラウザー/POST プロファイルの場合は、クライアントが POST 要求を発行します (ユーザーの介入の有無にかかわらず)。

アサーション コンシューマ サービスによる処理を迅速化するために、2 つの個別の URL が指定されます。

1. アサーション コンシューマー URL (ブラウザ/POST プロファイル)
2. アーティファクト レシーバー URL (ブラウザー/アーティファクト プロファイル)

これらおよびその他のエンドポイントの場所は、メタデータ ファイルに記録される場合があります。ID プロバイダーが信頼できるメタデータ ファイルを取得する方法、または特定のサービス プロバイダーの信頼できるエンドポイントの場所を決定する方法は、SAML 1.1 の範囲外です。

準拠する SAML 1.1 アイデンティティ プロバイダーは、サイト間転送サービスを提供する必要があることに注意してください。同様に、SAML 1.1 サービス プロバイダーは、アサーション コンシューマー サービスを提供する必要があります。

SAML 1.1 ブラウザ/POST プロファイルでは、次の 4 つの手順が指定されています。元の仕様で使用されている用語は、SAML 2.0 仕様に準拠するように若干変更されています。

メッセージ フローは、IdP に向けられたリクエストから始まります。

プリンシパルは (HTTP ユーザー エージェント経由で) アイデンティティ プロバイダーのサイト間転送サービスを要求します。

https://idp.example.org/TransferService?TARGET=ターゲット

ここで、 はtargetサービス プロバイダーの目的のリソースです (https://sp.example.com/home など)。つまり、次の GET 要求は、ユーザー エージェントによって SSL/TLS 経由で発行されます。

GET  /TransferService?TARGET=ターゲット HTTP / 1.1
ホスト:  idp.example.org

TARGETプロファイルでは、ユーザー エージェントが 転送サービスへの URL (パラメータ付き) を取得する方法が指定されていません。

サイト間転送サービスは、次のFORM要素を含む HTML ドキュメントを返します。

HTTP / 1.1  200  OK
コンテンツ タイプ:  text/html
コンテンツの長さ:  nnnn 
... 
<フォーム メソッド= "post" アクション= "https://sp.example.com/ACS/POST"  ... > 
<入力タイプ= "hidden"名前= "TARGET"値= "target" /> <入力タイプ= "hidden"名前= "SAMLResponse"値= "''response''" />      
      
  ...
  < input  type = "submit"  value = "送信"  /> 
</ form >
...

ここで、TARGETパラメータはステップ 1 から保持されています。パラメータの値は、次のような SAMLResponseSAML 要素の base64 エンコードです。Response

  <samlp:Response 
xmlns:samlp= "urn:oasis:names:tc:SAML:1.0:protocol" MajorVersion= "1" MinorVersion= "1" ResponseID= "_P1YaA+Q/wSM/t/8E3R8rNhcpPTM=" IssueInstant= "2002-06-19T17:05:37.795Z" > <ds:Signature xmlns:ds= "http://www.w3.org/2000/09/xmldsig#" > ... </ds:Signature> <samlp:Status> <samlp:StatusCode Value= "samlp:Success" /> </samlp:Status> <saml:Assertion xmlns:saml= "urn:oasis:names:tc:SAML:1.0:assertion" MajorVersion= "1"マイナーバージョン = "1"アサーションID = "buGxcG4gILg5NlocyLccDz6iXrUa"発行者 = "https://idp.example.org/saml"問題インスタント = "2002-06-19T17:05:37.795Z" > <saml:Conditions NotBefore = "2002-06-19T17:00:37.795Z" NotOnOrAfter = "2002-06-19T17:10:37.795Z" /> <saml:AuthenticationStatement認証方法 = "urn:oasis:names:tc:SAML:1.0:am:password"認証インスタント = "2002-06-19T17:05:17.706Z" > <saml:Subject> <saml:NameIdentifierフォーマット = "urn:oasis:names:tc:SAML:1.1:nameid-format:emailAddress" > user@idp.example.org
 </saml:NameIdentifier> <saml:SubjectConfirmation> <saml:ConfirmationMethod> urn:oasis:names:tc:SAML:1.0:cm:bearer
 </saml:ConfirmationMethod> </saml:SubjectConfirmation> </saml:Subject> </saml:AuthenticationStatement> </saml:Assertion> </samlp:Response>    
     
    
    
    
      
    
       
    
    
      
       
      
      
      
      
        
        
      
        
        
        
          
            
                      
          
            
                          
          
        
      
    
  

SAML レスポンスは、ID プロバイダーによってデジタル署名されている必要があります。

重要: プリンシパルが ID プロバイダーでセキュリティ コンテキストをすでに確立していることが前提となります。そうでない場合、サイト間転送サービスは SAML 要素で認証ステートメントを提供できませんResponse。

ユーザー エージェントは、サービス プロバイダーのアサーション コンシューマー サービスを要求します。

POST  /ACS/POST  HTTP / 1.1
ホスト:  sp.example.com
コンテンツタイプ:  application/x-www-form-urlencoded
コンテンツ長:  nnnn 
TARGET=target&SAMLResponse=response

TARGETここで、およびパラメータの値は、SAMLResponse手順 2 の HTML フォームから取得されます。

注: フォームの送信を自動化するには、ページ上の任意の場所に次の JavaScript 行を配置します。

  window.onload = function ( ) { document.forms [ 0 ] .submit ( ) ; }​      

もちろん、これはページに単一のFORM要素 ( forms[0]) が含まれていることを前提としています。

アサーション コンシューマ サービスは SAMLResponse要素を消費し、サービス プロバイダーでセキュリティ コンテキストを作成し、ユーザー エージェントをターゲット リソースにリダイレクトします。

SAML 1.1 ブラウザ/アーティファクト プロファイルでは、次の 6 つの手順が指定されています。元の仕様で使用されている用語は、SAML 2.0 仕様に準拠するように若干変更されています。

メッセージ フローは、IdP に向けられたリクエストから始まります。

プリンシパルは (HTTP ユーザー エージェント経由で) アイデンティティ プロバイダーのサイト間転送サービスを要求します。

https://idp.example.org/TransferService?TARGET=ターゲット

ここで、 はtargetサービス プロバイダーの目的のリソースです (https://sp.example.com/home など)。つまり、次の GET 要求は、ユーザー エージェントによって SSL/TLS 経由で発行されます。

GET  /TransferService?TARGET=ターゲット HTTP / 1.1
ホスト:  idp.example.org

プロファイルでは、転送サービスへの URL (TARGETパラメータ付き) がユーザー エージェントによって取得される方法は指定されません。

プリンシパルはサービス プロバイダーのアサーション コンシューマー サービスにリダイレクトされます。つまり、次の応答がユーザー エージェントに返されます。

HTTP / 1.1  302 見つかった
場所:  https://sp.example.com/ACS/Artifact?TARGET=target&SAMLart=artifact

ここで、はartifact、アイデンティティ プロバイダーが要求に応じて提供するアサーションへの参照です。

重要: プリンシパルが ID プロバイダーでセキュリティ コンテキストをすでに確立していることが前提となります。そうでない場合、サイト間転送サービスは認証ステートメントを提供できません。

ユーザー エージェントは、サービス プロバイダーのアサーション コンシューマー サービスを要求します。

https://sp.example.com/ACS/Artifact?TARGET=ターゲット&SAMLart=アーティファクト

ここでtarget、 およびartifactは前と同じです。つまり、次の GET リクエストは、ユーザー エージェントによって SSL/TLS 経由で発行されます。

GET  /ACS/Artifact?TARGET=target&SAMLart=artifact  HTTP / 1.1
ホスト:  sp.example.com

サービス プロバイダーのアサーション コンシューマー サービスは、アイデンティティ プロバイダーのアーティファクト解決サービスとのバックチャネル交換を開始します。SAML SOAP メッセージは、HTTP POST 要求にバインドされます。

POST  /アーティファクト解決サービス HTTP/1.1
ホスト:  idp.example.org
コンテンツタイプ:  text/xml
コンテンツの長さ:  nnn
SOAP アクション:  http://www.oasis-open.org/committees/security
 <SOAP-ENV:Envelope 
xmlns:SOAP-ENV= "http://schemas.xmlsoap.org/soap/envelope/" > <SOAP-ENV:Header/> <SOAP-ENV:Body> <samlp:Request xmlns:samlp= "urn:oasis:names:tc:SAML:1.0:protocol" MajorVersion= "1" MinorVersion= "1" RequestID= "_192.168.16.51.1024506224022" IssueInstant= "2002-06-19T17:03:44.022Z" > <samlp:AssertionArtifact>アーティファクト
</samlp:AssertionArtifact> </samlp:Request> </SOAP-ENV:本文> </SOAP-ENV:エンベロープ>  
  
  
    
      
       
      
      
      
              
    
  

これはartifact、ステップ 2 と 3 で ID プロバイダーからサービス プロバイダーに送信されたものです。

アイデンティティ プロバイダーは、SAML SOAP メッセージにバインドされた SAML アサーションで応答することにより、バックチャネル交換を完了します。

HTTP/1.1  200  OK
コンテンツタイプ:  text/xml
コンテンツ長:  nnnn
 <SOAP-ENV:Envelope 
xmlns:SOAP-ENV= "http://schemas.xmlsoap.org/soap/envelope/" > <SOAP-ENV:Header/> <SOAP-ENV:Body> <samlp:Response xmlns:samlp= "urn:oasis:names:tc:SAML:1.0:protocol" MajorVersion= "1" MinorVersion= "1" ResponseID= "_P1YaA+Q/wSM/t/8E3R8rNhcpPTM=" InResponseTo= "_192.168.16.51.1024506224022" IssueInstant= "2002-06-19T17:05:37.795Z" > <samlp:Status> <samlp:StatusCode Value= "samlp:Success" /> </samlp:Status> <saml:Assertion xmlns:saml= "urn:oasis:names:tc:SAML:1.0:assertion" MajorVersion= "1" MinorVersion= "1" AssertionID= "buGxcG4gILg5NlocyLccDz6iXrUa" Issuer= "https://idp.example.org/saml" IssueInstant= "2002-06-19T17:05:37.795Z" > <saml:Conditions NotBefore= "2002-06-19T17:00:37.795Z" NotOnOrAfter= "2002-06-19T17:10:37.795Z" /> <saml:AuthenticationStatement AuthenticationMethod= "urn:oasis:names:tc:SAML:1.0:am:password" AuthenticationInstant= "2002-06-19T17:05:17.706Z" > <saml:Subject> <saml:NameIdentifier Format= "urn:oasis:names:tc:SAML:1.1:nameid-format:emailAddress" > user@idp.example.org
 </saml:NameIdentifier> <saml:SubjectConfirmation> <saml:ConfirmationMethod> urn:oasis:names:tc:SAML:1.0:cm:artifact
 </saml:ConfirmationMethod> </saml:SubjectConfirmation> </saml:Subject> </saml:AuthenticationStatement> </saml:Assertion> </samlp:Response> </SOAP-ENV:Body> </SOAP-ENV:Envelope>  
  
  
    
      
       
      
      
      
      
         
      
      
        
         
        
        
        
        
          
          
        
          
          
          
            
              
                          
            
              
                              
            
          
        
      
    
  

この場合、認証ステートメントにはNameIdentifierプリンシパルの電子メール アドレスを含む が含まれます。

アサーション コンシューマ サービスは SAMLResponse要素を解析し、サービス プロバイダーでセキュリティ コンテキストを作成し、ユーザー エージェントをターゲット リソースにリダイレクトします。

• サムエル
• SAM 2.0 の概要
• SAMLベースの製品とサービス