7.2. SAML


SAML 2.0 は OIDC と同様の仕様ですが、より古く、より成熟したものです。SOAP と plethora の WS-* 仕様にはルートがあるため、OIDC よりも詳細度が少しなる傾向があります。SAML 2.0 は主に、認証サーバーとアプリケーション間の XML ドキュメント変更によって機能する認証プロトコルです。XML 署名と暗号化は、要求と応答の検証に使用されます。

SAML を使用する場合は、主に 2 つのタイプのユースケースがあります。1 つ目のアプリケーションは、Red Hat Single Sign-On サーバーがユーザーを認証するよう依頼するアプリケーションです。ログインが成功すると、アプリケーションには、ユーザーのさまざまな属性を指定する SAML アサーションが含まれる XML ドキュメントを受け取ります。XML ドキュメントはレルムによってデジタル署名され、アプリケーションでユーザーがアクセスできるリソースを判別するためにアプリケーションが使用できるアクセス情報 (ユーザーロールマッピングなど) が含まれます。

2 つ目のタイプのユースケースは、リモートサービスへのアクセスを取得するクライアントのものです。この場合、クライアントはユーザーの代わりに他のリモートサービスで起動するのに使用できる SAML アサーションを取得するよう Red Hat Single Sign-On に要求します。

7.2.1. SAML バインディング

SAML は、認証プロトコルの実行時に XML ドキュメントを交換するさまざまな方法を定義します。Redirect および Post のバインディングはブラウザーベースのアプリケーションに対応します。ECP バインディングは、REST 呼び出しに対応します。他のバインディングタイプがありますが、Red Hat Single Sign-On はこれら 3 つのみをサポートします。

7.2.1.1. リダイレクトバインディング

Redirect バインディングは一連のブラウザーリダイレクト URI を使用して情報を交換します。これは、その仕組みの概要です。

  1. ユーザーがアプリケーションにアクセスでき、アプリケーションによってユーザーが認証されないことが検索されます。これは XML 認証リクエストドキュメントを生成し、これを Red Hat Single Sign-On サーバーにリダイレクトするために使用される URI で query param としてエンコードします。設定によっては、アプリケーションはこの XML ドキュメントにデジタル署名し、この署名をリダイレクト URI の Red Hat Single Sign-On へのクエリーパラメーターとしても使用できます。この署名は、このリクエストを送信したクライアントの検証に使用されます。
  2. ブラウザーが Red Hat Single Sign-On にリダイレクトされます。サーバーは XML 認証要求のドキュメントを抽出し、必要に応じてデジタル署名を検証します。ユーザーは、認証されるクレデンシャルに入力する必要があります。
  3. 認証後、サーバーは XML 認証応答ドキュメントを生成します。このドキュメントには、名前、アドレス、電子メールなどのユーザーに関するメタデータを保持する SAML アサーションが含まれ、ユーザーが持つ可能性のあるロールマッピングが含まれます。このドキュメントはほぼ常に XML 署名を使用してデジタル署名されており、暗号化される可能性もあります。
  4. その後、XML 認証応答ドキュメントは、ブラウザーをアプリケーションに戻すリダイレクト URI でクエリーパラメーターとしてエンコードされます。デジタル署名は、クエリーパラメーターとしても含まれています。
  5. アプリケーションはリダイレクト URI を受け取り、XML ドキュメントを展開してレルムの署名を検証し、有効な認証応答を受信していることを確認します。その後、SAML アサーション内の情報を使用して、アクセスの決定やユーザーデータの表示に使用されます。

7.2.1.2. POST バインディング

SAML POST バインディングは、Redirect バインディングとほぼ同じように動作しますが、GET リクエストの代わりに XML ドキュメントは POST リクエストによって交換されます。POST バインディングは JavaScript を使用してブラウザーを漏洩し、ドキュメント交換時に Red Hat Single Sign-On サーバーまたはアプリケーションへの POST リクエストを行います。基本的には、HTTP 応答には、埋め込み JavaScript のある HTML 形式が含まれる HTML ドキュメントが含まれています。ページが読み込まれると、JavaScript は自動的にフォームを呼び出します。本当にこのお気に入りについて把握する必要はありませんが、これは非常に分かりやすくなります。

通常、POST バインディングはセキュリティーおよびサイズの制限により推奨されます。REDIRECT を使用する場合、SAML 応答は URL の一部となる (以前説明されるようにクエリーパラメーターですが) 、ログ内でキャプチャーされ、安全性は少なくなる可能性があります。サイズに関しては、アサーションが多くの属性または大きな属性を含んでいる場合、HTT Pペイロード内で文書を送信することは、より制限された URL 内よりも常に優れています。

7.2.1.3. ECP

ECP は「Enhanced Client or Proxy」、SAML v.2.0 プロファイルを表します。これにより、Web ブラウザーのコンテキスト外にある SAML 属性を交換できます。これは、REST または SOAP ベースのクライアントで最もよく使用されます。

トップに戻る
Red Hat logoGithubredditYoutubeTwitter

詳細情報

試用、購入および販売

コミュニティー

Red Hat ドキュメントについて

Red Hat をお使いのお客様が、信頼できるコンテンツが含まれている製品やサービスを活用することで、イノベーションを行い、目標を達成できるようにします。 最新の更新を見る.

多様性を受け入れるオープンソースの強化

Red Hat では、コード、ドキュメント、Web プロパティーにおける配慮に欠ける用語の置き換えに取り組んでいます。このような変更は、段階的に実施される予定です。詳細情報: Red Hat ブログ.

会社概要

Red Hat は、企業がコアとなるデータセンターからネットワークエッジに至るまで、各種プラットフォームや環境全体で作業を簡素化できるように、強化されたソリューションを提供しています。

Theme

© 2025 Red Hat