アイデンティティプロバイダ（IdP）、サービスプロバイダ（SP）、およびブラウザ経由でリダイレクトする方法について、一連のフローチャートを見てきました。しかし、今は私にとっては不必要なように思えるので、私は何かが欠けていることを知っています。
SAMLアーティファクトを使用しない場合と比較してSAMLアーティファクトが必要なユースケースを教えてもらえますか？SAMLアーティファクトの目的は何ですか？
ありがとうございます。
通常、アーティファクトバインディングの目的は、ブラウザ自体を介したSAMLメッセージのフローを減らすことです。これは、ブラウザの制限（クエリ文字列/ POSTペイロードサイズに制限があるブラウザ）またはJavaScript（自動送信フォームの場合）をサポートしないこと、またはSAMLメッセージの転送方法のセキュリティモデルを改善することが原因である可能性があります。成果物を使用することによって、SAMLアサーション/属性ステートメントを介して運ばれる機密データはブラウザを通過しないため、エンドユーザーまたはサイトとエンドユーザーの間の攻撃者から隠すことができます。この機密データは、バックチャネル検索によってサイト間でのみ直接解決されます。 SAML 2.0 Bindings specsの
3.6.2は最高のそれを要約したものです。
HTTPアーティファクトは、結合がSAML 要求側と応答側が仲介者としてHTTPユーザーエージェント を使用して通信する必要のある場合を対象とし、仲介者の制限により、メッセージ全体（またはメッセージ交換）の送信が妨げられることはない（ ）。これは、技術的な理由、またはメッセージコンテンツを仲介者に公開したくないためです（ 暗号化の使用が実用的でない場合）。 SOAPなどの別の同期 バインディングを使用してアーティファクトを後で解決する必要があるため、 があるため、 アーチファクトの逆方向の とSAMLメッセージの送信者と受信者の間に直接通信パスが存在する必要があります。メッセージとアーティファクトは、 アーティファクト 発行者にリクエストを返すことができる必要があります）。アーチファクト発行者は、 アーチファクトが保留中の状態も維持する必要があり、ロードバランシング 環境に影響します。
SAMLメッセージは、値または参照によってエンティティから別のエンティティに送信されます。 の参照とSAMLメッセージは、アーチファクトと呼ばれます。アーティファクトの受信者は、アーティファクトの発行者に直接リクエストを送信することによってリファレンスを解決し、アーティファクトが参照する実際のメッセージで応答します。
は、実際のメッセージを取得する方法はありませんアーティファクトがないとSAML 2.0、
を参照してください。
これは、HTTPアーティファクトバインディングを使用する場合にのみ必要であることに注意してください。 （単純なSAMLメッセージを送信するより一般的なHTTP POSTバインディングとは対照的に）。
HTTPアーティファクトバインディングを使用するもう1つの理由は、SSLを使用してSAMLメッセージの整合性と機密性を保証できることです。 SAMLリクエスタとレスポンダは、SAMLメッセージの署名、検証、暗号化、および復号化を行う必要はありません。
スコットTの回答を展開すると、SAMLアーティファクトプロファイルはセキュリティを強化するように設計されています。ユーザーがSAMLアサーションの中間トラフィック（ユーザー名、ロールなどの変更など）を変更できないようにするため、開発者はXML署名を使用してアサーションに署名することをお勧めします。 XML署名は、既存のXMLパーサーのすべての言語の問題のため、XMLラッピング攻撃に対して非常に脆弱です。 https://www.usenix.org/conference/usenixsecurity12/breaking-saml-be-whoever-you-want-beを参照して、SAMLアサーションに対するXMLラッピング攻撃の動作を確認してください。
SAMLアーチファクトプロファイルは、SAMLアサーションではなくリダイレクトまたはポストを介して、ユーザがサービスプロバイダに渡す1回限りの「アーティファクト」を作成することで、この問題を解決します。サービス提供者は、ワンタイムユースアーティファクトを受信すると、アイデンティティプロバイダのアーティファクト解決サービス（ARS）にSAMLアーティファクト解決要求（アーティファクトを含む）を送信する。その後、ARSはSAMLアーチファクトレスポンス（ユーザのSAMLアサーションを含む）で応答し、SAMLアサーションがバックチャネルを介してサービスプロバイダによって直接受け取られるため、ユーザによって修正されることを防止する。
これは興味深いと思われるかもしれませんが、ユーザエージェントとsp & idpサーバとの間に帯域幅が狭く、sp & idpの帯域幅がある場合、アーチファクトプロファイルも役立ちます。 （重い）アサーションはidpからuaへ、そしてuaからspへと循環せず、特定のサーカストーンでより良いパフォーマンスを示すかもしれません。