Loading article…
セキュリティアサーションマークアップ言語（SAML、発音はサムエル、/ ˈsæməl /）[ 1 ]は、当事者間、特にアイデンティティプロバイダーとサービスプロバイダー間で認証および認可データを交換するためのオープンスタンダードです。SAMLは、セキュリティアサーション（サービスプロバイダーがアクセス制御の決定を行うために使用するステートメント）のためのXMLベースのマークアップ言語です。SA MLには、次の特徴もあります。
SAMLが扱う重要なユースケースの1つは、Webブラウザのシングルサインオン（SSO）です。セキュリティドメイン内ではシングルサインオンは比較的簡単に実現できますが（たとえば、 Cookieを使用）、セキュリティドメインをまたいでSSOを拡張するのはより困難であり、相互運用性のない独自のテクノロジーが乱立する結果となりました。SAML Web Browser SSOプロファイルは、相互運用性を促進するために規定され、標準化されました。[ 2 ]実際には、SAML SSOはクラウドベースのビジネスソフトウェアへの認証に最も一般的に使用されています。[ 3 ]
SAML仕様では、プリンシパル（通常は人間ユーザー）、IDプロバイダー（IdP）、サービスプロバイダー（SP）の3つの役割が定義されています。SAMLが想定する主なユースケースでは、プリンシパルがサービスプロバイダーにサービスを要求します。サービスプロバイダーはIDプロバイダーに認証アサーションを要求し、これを取得します。サービスプロバイダーはこのアサーションに基づいてアクセス制御の決定、つまり接続されたプリンシパルに対してサービスを提供するかどうかを決定できます。
SAML アサーションの中心には、何らかの主張の対象となる主体 (特定のセキュリティ ドメインのコンテキストにおけるプリンシパル) が存在します。主体は通常 (必ずしもそうとは限りませんが) 人間です。SAML 2.0 テクニカル 概要[ 4 ]と同様に、主体とプリンシパルという用語は互換的に使用されます。
ID プロバイダからサービスプロバイダに主体ベースのアサーションを送信する前に、ID プロバイダはプリンシパルを認証するためにプリンシパルからいくつかの情報 (ユーザー名やパスワードなど) を要求する場合があります。SAML は、ID プロバイダからサービスプロバイダに渡されるアサーションの内容を規定します。SAML では、1 つの ID プロバイダが多くのサービスプロバイダに SAML アサーションを提供できます。同様に、1 つのサービスプロバイダ (SP) は、多くの独立した ID プロバイダ (IdP) からのアサーションに依存し、信頼することができます。[ 5 ]
SAML は、ID プロバイダーでの認証方法を規定していません。ID プロバイダーは、ユーザー名とパスワード、または多要素認証やKerberosチケットなどの他の形式の認証を使用する場合があります。ユーザー名とパスワードでユーザーがログインできるRADIUSやLDAPなどのディレクトリサービスは、ID プロバイダーでの認証トークンの典型的なソースです。[ 6 ] 人気のインターネット ソーシャル ネットワーキング サービスも、理論的には SAML 交換をサポートするために使用できる ID サービスを提供しています。
構造化情報標準推進機構（OASIS）セキュリティサービス技術委員会（SSTC）は、2001年1月に初めて会合を開き、「認証および認可情報を交換するためのXMLフレームワークを定義する」ことを目的として設立されました。[ 7 ]この目的のために、同年最初の2か月間にSSTCに以下の知的財産が提供されました。
これらの初期の貢献に基づいて、2002年11月にOASISはセキュリティアサーションマークアップ言語（SAML） 1.0仕様をOASIS標準として発表しました。[ 8 ]
一方、企業、非営利団体、政府機関からなる大規模なコンソーシアムであるLiberty Allianceは、Liberty Identity Federation Framework（ID-FF）と呼ばれるSAML標準の拡張を提案した。 [ 9 ] SAMLの前身と同様に、Liberty ID-FFは、標準化されたクロスドメインのWebベースのシングルサインオンフレームワークを提案した。さらに、Libertyは、参加する各ドメインが、ユーザーを識別するために使用されるプロセス、使用される認証システムの種類、および結果として得られる認証資格情報に関連付けられたポリシーを正確に文書化することが信頼される信頼の輪について説明した。信頼の輪の他のメンバーは、これらのポリシーを検証して、そのような情報を信頼するかどうかを判断できる。[ 10 ]
Liberty が ID-FF を開発している間、SSTC は SAML 標準のマイナーアップグレードに着手しました。その結果、SAML 1.1 仕様が 2003 年 9 月に SSTC によって承認されました。その後、同年 11 月にLiberty は ID-FF 1.2 を OASIS に提供し、SAML の次のメジャーバージョンの種を蒔きました。2005 年 3 月に、SAML 2.0 が OASIS 標準として発表されました。SAML 2.0 は、Liberty ID-FF とShibbolethプロジェクトによって提供された独自の拡張機能、および SAML 自体の初期バージョンが統合されたものです。ほとんどの SAML 実装は v2.0 をサポートしていますが、多くの実装は後方互換性のために v1.1 もサポートしています。2008 年 1 月までに、SAML 2.0 の導入は世界中の政府、高等教育機関、および商業企業で一般的になりました。[ 10 ]
SAMLはバージョン1.0以降、1回のマイナーアップデートと1回のメジャーアップデートを受けています。
リバティ・アライアンスは、2003年9月にOASIS SSTCにアイデンティティ・フェデレーション・フレームワーク（ID-FF）を提供した。
SAML のバージョン 1.0 と 1.1 は、わずかな違いはあるものの類似しています。[ 11 ] しかし、SAML 2.0 と SAML 1.1の違いは 大きいです。2 つの標準は同じユース ケースに対応していますが、SAML 2.0 は前バージョンと互換性がありません。
ID-FF 1.2はSAML 2.0の基盤としてOASISに貢献しましたが、SAML 2.0とID-FF 1.2 にはいくつかの重要な違いがあります。特に、2つの仕様は共通のルーツを持つにもかかわらず、互換性がありません。[ 10 ]
SAMLは、既存のいくつかの標準規格に基づいて構築されています。
SAMLは、XMLベースのアサーション、プロトコル、バインディング、およびプロファイルを定義します。SAML Coreという用語は、SAMLアサーションの一般的な構文と意味論、およびそれらのアサーションをあるシステムエンティティから別のシステムエンティティに要求および送信するために使用されるプロトコルを指します。SAML プロトコルは、送信される内容を指し、送信方法を指すものではありません（送信方法はバインディングの選択によって決まります）。したがって、SAML Coreは、SAMLリクエスト要素とレスポンス要素とともに、「ベア」SAMLアサーションを定義します。
SAMLバインディングは、 SAMLリクエストとレスポンスが標準のメッセージングプロトコルまたは通信プロトコルにどのようにマッピングされるかを決定します。重要な（同期）バインディングとして、SAML SOAPバインディングがあります。
SAMLプロファイルとは、特定のアサーション、プロトコル、およびバインディングの組み合わせを用いて、定義されたユースケースを具体的に表現したものです。
SAMLアサーションには、セキュリティ情報パケットが含まれています。
<saml:Assertion ...> … </saml:Assertion>
大まかに言えば、依拠当事者は主張を次のように解釈する。
条件Cが有効である場合、発行者Rは対象Sに関して時刻tに主張Aを発行した。
SAMLアサーションは通常、IDプロバイダーからサービスプロバイダーに転送されます。アサーションには、サービスプロバイダーがアクセス制御の決定を行うために使用するステートメントが含まれています。SAMLでは、次の3種類のステートメントが提供されます。
認証ステートメントは、サービスプロバイダに対し、プリンシパルが特定の時間に特定の認証方法を用いてIDプロバイダで認証を行ったことを確約するものです。認証ステートメントには、認証されたプリンシパルに関するその他の情報（認証コンテキストと呼ばれる）が含まれる場合があります。
属性ステートメントは、プリンシパルが特定の属性に関連付けられていることを表明します。属性とは、単に名前と値のペアです。依拠当事者は、アクセス制御の決定を行うために属性を使用します。
認可決定ステートメントは、証拠Eに基づいて、プリンシパルがリソースRに対してアクションAを実行することが許可されていることを表明します。SAMLにおける認可決定ステートメントの表現力は意図的に制限されています。より高度なユースケースでは、代わりにXACMLを使用することが推奨されます。
SAMLプロトコルは、特定のSAML要素（アサーションを含む）がSAMLリクエスト要素およびレスポンス要素内にどのようにパッケージ化されるかを規定し、SAMLエンティティがこれらの要素を生成または消費する際に従うべき処理規則を示します。SAMLプロトコルは、大部分において、単純なリクエスト・レスポンスプロトコルです。
SAMLプロトコルの最も重要なリクエストはクエリと呼ばれます。サービスプロバイダは、セキュアなバックチャネルを介してIDプロバイダに直接クエリを送信します。そのため、クエリメッセージは通常SOAPにバインドされます。
3種類のステートメントに対応して、SAMLクエリにも3種類あります。
属性クエリの結果は、アサーションを含むSAMLレスポンスであり、そのアサーション自体に属性ステートメントが含まれています。属性クエリ/レスポンスの例については、SAML 2.0のトピックを参照してください。
SAML 1.1では、クエリ以外に他のプロトコルは規定されていません。
SAML 2.0では、プロトコル の概念が大幅に拡張されています。SAML 2.0 Coreでは、以下のプロトコルについて詳細に説明しています。
これらのプロトコルのほとんどは、SAML 2.0で新たに導入されたものです。
SAMLバインディングとは、SAMLプロトコルメッセージを標準的なメッセージング形式や通信プロトコルにマッピングするものです。例えば、SAML SOAPバインディングは、SAMLメッセージがSOAPエンベロープにどのようにカプセル化されるかを指定し、そのSOAPエンベロープ自体はHTTPメッセージにバインドされます。
SAML 1.1では、SAML SOAPバインディングという1つのバインディングのみが規定されています。SOAPに加えて、SAML 1.1 WebブラウザSSOには、HTTP POSTバインディング、HTTPリダイレクトバインディング、HTTPアーティファクトバインディングの前身となるものが暗黙的に含まれています。ただし、これらは明示的に定義されておらず、SAML 1.1 WebブラウザSSOと組み合わせてのみ使用されます 。バインディングの概念は、SAML 2.0まで完全には開発されていません 。
SAML 2.0では、バインディングの概念と基盤となるプロファイルが完全に分離されています。実際、SAML 2.0には、以下の独立したバインディングを定義する全く新しいバインディング仕様があります。
この再編成により、非常に高い柔軟性が実現します。WebブラウザSSOだけでも、サービスプロバイダは4つのバインディング（HTTPリダイレクト、HTTP POST、および2種類のHTTPアーティファクト）から選択でき、IDプロバイダは3つのバインディングオプション（HTTP POSTと2種類のHTTPアーティファクト）を選択できるため、SAML 2.0 WebブラウザSSOプロファイルの展開方法は合計12通りになります。
SAMLプロファイルは、SAMLアサーション、プロトコル、およびバインディングがどのように組み合わさって特定のユースケースをサポートするかを詳細に記述します。最も重要なSAMLプロファイルは、WebブラウザSSOプロファイルです。
SAML 1.1 では、Web ブラウザ SSO の 2 つの形式、Browser/Artifact プロファイルと Browser/POST プロファイルが規定されています。後者はアサーションを値渡しするのに対し、Browser/Artifact はアサーションを参照渡しします。そのため、Browser/Artifact では SOAP を介したバックチャネル SAML 交換が必要です。SAML 1.1 では、簡略化のため、すべてのフローは ID プロバイダへのリクエストから始まります。基本的な IdP 開始フローに対する独自の拡張機能が提案されています (例えばShibbolethによる)。
Web ブラウザ SSO プロファイルは、SAML 2.0 用に完全に再設計されました。概念的には、SAML 1.1 の Browser/Artifact と Browser/POST は、SAML 2.0 Web ブラウザ SSO の特殊なケースです。後者は、SAML 2.0 の新しい「プラグアンドプレイ」バインディング設計により、SAML 1.1 の対応物よりもはるかに柔軟です 。以前のバージョンとは異なり、SAML 2.0 のブラウザ フローは、サービス プロバイダへのリクエストから始まります。これにより柔軟性が向上しますが、SP 開始フローは、今日多くの研究の対象となっている、いわゆるID プロバイダ検出問題を引き起こします。Web ブラウザ SSO に加えて、SAML 2.0 では多数の新しいプロファイルが導入されています。
SAML Web Browser SSOプロファイル以外にも、SAMLの重要なサードパーティプロファイルには以下のようなものがあります。
SAMLの仕様では、さまざまなセキュリティメカニズムが推奨されており、場合によっては義務付けられています。
要件は多くの場合、（相互）認証、完全性、機密性といった言葉で表現され、セキュリティメカニズムの選択は実装者と展開者に委ねられる。
SAMLの主なユースケースは、Webブラウザのシングルサインオン（SSO）です。ユーザーは、ユーザーエージェント（通常はWebブラウザ）を使用して、SAMLサービスプロバイダによって保護されているWebリソースを要求します。サービスプロバイダは、要求元のユーザーの身元を確認するために、ユーザーエージェントを介してSAML IDプロバイダに認証要求を発行します。その結果として生じるプロトコルフローを次の図に示します。
https://sp.example.com/myresourceサービスプロバイダは、対象リソースに代わってセキュリティチェックを実行します。サービスプロバイダに有効なセキュリティコンテキストが既に存在する場合は、手順2～7をスキップしてください。
https://idp.example.org/SAML2/SSO/Redirect?SAMLRequest=requestパラメータの値
SAMLRequest（上記のプレースホルダーで示されているrequest）は、圧縮された要素のBase64エンコードです。<samlp:AuthnRequest>AuthnRequest（SAMLRequestURLクエリパラメータ経由で送信された）情報を処理し、セキュリティチェックを実行します。ユーザーが有効なセキュリティコンテキストを持っていない場合、IDプロバイダがユーザーを識別します（詳細は省略）。< form method = "post" action = "https://sp.example.com/SAML2/SSO/POST" ... > < input type = "hidden" name = "SAMLResponse" value = "response" /> ... < input type = "submit" value = "送信" / > </form>SAMLResponse（上記のプレースホルダーで示されているresponse）は、要素のbase64エンコードです<samlp:Response>。SAMLResponseパラメータの値は、ステップ4のXHTMLフォームから取得されます。https://sp.example.com/myresource
SAML 1.1では、ステップ3でIDプロバイダーのサイト間転送サービスへのリクエストからフローが始まります。
上記の例のフローでは、図示されているすべてのやり取りはフロントチャネルのやり取りです。つまり、HTTPユーザーエージェント（ブラウザ）が各ステップでSAMLエンティティと通信します。特に、バックチャネルのやり取りや、サービスプロバイダとIDプロバイダ間の直接通信はありません。フロントチャネルのやり取りは、すべてのメッセージが単純なHTTPバインディング（GETまたはPOST）を使用して値渡しされる、シンプルなプロトコルフローにつながります。実際、前のセクションで概説したフローは、軽量WebブラウザSSOプロファイルと呼ばれることもあります。
あるいは、セキュリティやプライバシーを強化するために、メッセージは参照渡しされる場合もあります。例えば、IDプロバイダは、ユーザーエージェントを介してアサーションを直接送信する代わりに、SAMLアサーションへの参照（アーティファクトと呼ばれる）を提供する場合があります。その後、サービスプロバイダはバックチャネルを介して実際のアサーションを要求します。このようなバックチャネルでのやり取りは、SOAPメッセージ交換（SAML over SOAP over HTTP）として指定されます。一般的に、セキュアなバックチャネルを介したSAML交換はすべてSOAPメッセージ交換として行われます。
バックチャネルでは、SAMLはSOAP 1.1の使用を規定しています。ただし、バインディングメカニズムとしてSOAPを使用するかどうかは任意です。SAMLの導入環境は、状況に応じて適切なバインディングを選択します。