SAML Basics
Last updated
Last updated
Learn & practice AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE) Learn & practice GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE)
Security Assertion Markup Language (SAML) は、アイデンティティプロバイダー (IdP) がサービスプロバイダー (SP) に認証情報を送信するために利用され、シングルサインオン (SSO) を促進します。このアプローチは、複数のウェブサイトで単一の認証情報セットを使用できるようにすることで、複数のログインの管理を簡素化します。IdP と SP の間の標準化された通信のために XML を活用し、ユーザーのアイデンティティの認証とサービスの認可をリンクします。
SAML は、企業に SSO ログインセキュリティに対するより大きな制御を提供するように設計されています。
OAuth は、よりモバイルフレンドリーで、JSON を使用し、Google や Twitter などの企業の共同作業によるものです。
詳細については、https://epi052.gitlab.io/notes-to-self/blog/2019-03-07-how-to-test-saml-a-methodology/ の完全な投稿を確認してください。これは要約です：
SAML 認証プロセスは、スキーマに示されているように、いくつかのステップを含みます：
リソースアクセスの試行: ユーザーが保護されたリソースにアクセスしようとします。
SAML リクエストの生成: SP はユーザーを認識せず、SAML リクエストを生成します。
IdP へのリダイレクト: ユーザーは IdP にリダイレクトされ、SAML リクエストがユーザーのブラウザを通過します。
IdP がリクエストを受信: IdP は SAML リクエストを受信します。
IdP での認証: IdP はユーザーを認証します。
ユーザーの検証: IdP は要求されたリソースにアクセスするためのユーザーの正当性を検証します。
SAML レスポンスの作成: IdP は必要なアサーションを含む SAML レスポンスを生成します。
SP の ACS URL へのリダイレクト: ユーザーは SP のアサーションコンシューマサービス (ACS) URL にリダイレクトされます。
SAML レスポンスの検証: ACS は SAML レスポンスを検証します。
リソースアクセスの許可: 最初に要求されたリソースへのアクセスが許可されます。
ユーザーが https://shibdemo-sp1.test.edu/secure/ で安全なリソースへのアクセスを要求するシナリオを考えてみましょう。SP は認証がないことを認識し、SAML リクエストを生成します：
生のSAMLリクエストは次のようになります:
Key elements of this request include:
AssertionConsumerServiceURL: IdPが認証後にSAMLレスポンスを送信すべき場所を指定します。
Destination: リクエストが送信されるIdPのアドレス。
ProtocolBinding: SAMLプロトコルメッセージの伝送方法を定義します。
saml:Issuer: リクエストを開始したエンティティを識別します。
SAMLリクエストの生成に続いて、SPは302リダイレクトで応答し、ブラウザをSAMLリクエストがHTTPレスポンスのLocationヘッダーにエンコードされているIdPに向けます。RelayStateパラメータはトランザクション全体で状態情報を維持し、SPがSAMLレスポンスを受け取った際に最初のリソースリクエストを認識できるようにします。SAMLRequestパラメータは、生のXMLスニペットの圧縮およびエンコードされたバージョンで、Deflate圧縮とbase64エンコーディングを利用しています。
You can find a full SAML response here. The key components of the response include:
ds:Signature: このセクションはXML署名で、アサーションの発行者の整合性と真正性を保証します。例のSAMLレスポンスには、メッセージ用とアサーション用の2つのds:Signature要素が含まれています。
saml:Assertion: この部分はユーザーのアイデンティティに関する情報や他の属性を保持します。
saml:Subject: アサーション内のすべてのステートメントの主要な主体を指定します。
saml:StatusCode: 対応するリクエストに対する操作のステータスを表します。
saml:Conditions: アサーションの有効性のタイミングや指定されたサービスプロバイダーなどの条件を詳細に説明します。
saml:AuthnStatement: IdPがアサーションの主体を認証したことを確認します。
saml:AttributeStatement: アサーションの主体を説明する属性を含みます。
SAMLレスポンスに続いて、プロセスにはIdPからの302リダイレクトが含まれます。これにより、サービスプロバイダーのアサーションコンシューマサービス（ACS）URLへのPOSTリクエストが行われます。POSTリクエストにはRelayStateおよびSAMLResponseパラメータが含まれます。ACSはSAMLレスポンスの処理と検証を担当します。
POSTリクエストが受信され、SAMLレスポンスが検証されると、ユーザーが最初にリクエストした保護されたリソースへのアクセスが許可されます。これはGETリクエストを/secure/エンドポイントに送り、リソースへの成功したアクセスを示す200 OKレスポンスで示されます。
XML署名は多用途で、XMLツリー全体またはその特定の要素に署名することができます。レスポンス要素だけでなく、任意のXMLオブジェクトに適用できます。以下はXML署名の主要なタイプです。
XML署名は、以下のような基本要素で構成されています:
Each Reference element signifies a specific resource being signed, identifiable by the URI attribute.
包まれた署名: このタイプの署名は、署名されるリソースの子孫であり、署名は署名されたコンテンツと同じXML構造内に含まれています。
Example:
包まれた署名では、ds:Transform要素がenveloped-signatureアルゴリズムを通じて包まれていることを指定します。
包む署名: 包まれた署名とは対照的に、包む署名は署名されるリソースを包みます。
Example:
分離署名: このタイプは、署名されるコンテンツから独立しています。署名とコンテンツは独立して存在しますが、両者の間にはリンクが維持されています。
Example:
結論として、XML署名はXML文書を保護するための柔軟な方法を提供し、各タイプは異なる構造的およびセキュリティニーズに応じています。
Learn & practice AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE) Learn & practice GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE)
