saml とは？初心者向けに分かりやすく解説共起語・同意語・対義語も併せて解説！

この記事を書いた人

岡田康介

名前：岡田康介（おかだこうすけ）ニックネーム：コウ、または「こうちゃん」年齢：28歳性別：男性職業：ブロガー（SEOやライフスタイル系を中心に活動）居住地：東京都（都心のワンルームマンション）出身地：千葉県船橋市身長：175cm 血液型：O型誕生日：1997年4月3日趣味：カフェ巡り、写真撮影、ランニング、読書（自己啓発やエッセイ）、映画鑑賞、ガジェット収集性格：ポジティブでフランク、人見知りはしないタイプ。好奇心旺盛で新しいものにすぐ飛びつく性格。計画性がある一方で、思いついたらすぐ行動するフットワークの軽さもある。 1日（平日）のタイムスケジュール 7:00 起床：軽くストレッチして朝のニュースをチェック。ブラックコーヒーで目を覚ます。 7:30 朝ラン：近所の公園を30分ほどランニング。頭をリセットして新しいアイデアを考える時間。 8:30 朝食＆SNSチェック：トーストやヨーグルトを食べながら、TwitterやInstagramでトレンドを確認。 9:30 ブログ執筆スタート：カフェに移動してノートPCで記事を書いたり、リサーチを進める。 12:30 昼食：お気に入りのカフェや定食屋でランチ。食事をしながら読書やネタ探し。 14:00 取材・撮影・リサーチ：街歩きをしながら写真を撮ったり、新しいお店を開拓してネタにする。 16:00 執筆＆編集作業：帰宅して集中モードで記事を仕上げ、SEOチェックやアイキャッチ作成も行う。 19:00 夕食：自炊か外食。たまに友人と飲みに行って情報交換。 21:00 ブログのアクセス解析・改善点チェック：Googleアナリティクスやサーチコンソールを見て数字を分析。 22:00 映画鑑賞や趣味の時間：Amazonプライムで映画やドラマを楽しむ。 24:00 就寝：明日のアイデアをメモしてから眠りにつく。

saml とは？

SAML は Security Assertion Markup Language の略で、ウェブサービス間の認証情報のやり取りを標準化する XML ベースの規格です。難しく聞こえますが要点はシンプルです。一度のログインで複数のサービスにアクセスできる仕組みを作るための道具として使われます。

この仕組みには主に二つの役割があります。IdP は Identity Provider の略で、利用者の身元を確認します。SP は Service Provider の略で、実際のサービスを提供する側です。利用者が SP のサイトにアクセスすると、SP は IdP に認証を依頼します。 IdP が認証を完了すると、SAML アサーションという証拠を作成し、それを SP に渡して本人確認を完了させます。

このやり取りを通じて生まれる最大のメリットは SSO すなわち一度の認証で複数のサービスへ自動的にログインできる点です。企業内の複数のツールやクラウドサービスを使う場合にとても便利です。

SAML アサーションは XML 形式で作られ、本人の属性情報や認証結果が含まれます。 SP は受け取ったアサーションを検証し、有効であればアクセスを許可します。署名の検証や時刻の確認、 IdP との信頼設定などが関係します。これらは不正アクセスを防ぐための重要な要素です。

動作の流れ

able>1ユーザーが SP のサービスにアクセスする2SP は IdP に対して認証を要求するリダイレクトを返す3ユーザーは IdP の認証画面を通じて本人確認を行う4IdP は SAML アサーションを作成して SP に送信する5SP はアサーションを検証し、問題なければサービスの利用を許可するble>

利点と注意点

利点	一度の認証で複数のサービスにログインできる SSO。パスワードをサービス間で共有しないためセキュリティが向上します。
注意点	IdP と SP の設定が正しくないと認証に失敗します。時刻同期や証明書の更新など管理作業が発生します。
セキュリティのポイント	署名と暗号化、信頼関係の設定が重要です。これらが適切に行われていれば外部からの不正利用を防ぐ力が強くなります。

よくある誤解

SAML は万能ではないという点を覚えておきましょう。設定ミスや運用の不備が原因でログインに失敗することがあります。また SAML は本人の認証を IdP に任せ、アサーションと呼ばれる証拠を渡す仕組みだという点を理解しておくと混乱を避けられます。

使い方のヒント

導入を検討するときは最初に IdP の選択と SP との信頼設定を丁寧に行うことが大切です。時刻同期の確認、証明書の有効期限、署名アルゴリズムの互換性などを前もってチェックしましょう。

samlの関連サジェスト解説

saml とはわかりそうで: この記事では『saml とはわかりそうで』という疑問に答える形で、SAMLとは何か、どう使われるのかを、初心者にも分かりやすく解説します。SAMLはウェブサービスの認証を決まった形でやり取りする仕組みのひとつです。主役は IdP（アイデンティティプロバイダ）と SP（サービスプロバイダ）です。IdPは利用者のIDを確認する機関、SPは実際に使いたいWebサービスのことです。基本の流れはこうです。ユーザーがSPのサイトにアクセスすると、SPはユーザーをIdPへ転送してログインを促します。IdPで正しく認証されると、IdPはSAMLアサーションと呼ばれるデータをSPへ返します。SPはそのアサーションを検証して、ユーザーをログインさせます。これにより、1回のログインで複数のサービスを使える「SSO（シングルサインオン）」が実現します。SAMLの良い点は、パスワード管理をサービスごとに分けずに済むことや、企業内のセキュリティを一元化できる点です。一方で設定は難しく、IdPとSPの両方がSAML対応である必要があります。トラブル時にはIdPの設定ミスやネットワーク遅延が原因となることがあります。実務では、SAMLは企業のSSO導入でよく使われ、従業員が一度のログインで社内ツールへアクセスできるようになります。SAMLはOAuthやOpenID Connectと混同されがちですが、長い運用実績があり、主に企業内のSSOに適しています。初心者の方は、IdPとSP、SSO、アサーションといった基本用語を覚えると理解が進みます。
saml アサーションとは: saml アサーションとは、ウェブサービスへ安全にログインするための仕組みの中核です。SAMLは Security Assertion Markup Language の略で、別々のサービス間で“この人は誰か”という情報をやり取りする言語を指します。大きな特徴は、ユーザーが一度IDP（Identity Provider：本人確認を行う機関）で認証されれば、以降は別のサービスへ再度パスワードを入力する必要がない点です。これがSSO（シングルサインオン）と呼ばれる仕組みの土台になります。実際の流れをやさしく説明します。まず、あなたがあるクラウドサービスにアクセスしようとすると、そのサービス（SP: Service Provider）はあなたをIDPへリダイレクトします。IDPはあなたのユーザー名とパスワードを使って本人かどうかを確認します。認証が成功すると、IDPは“アサーション”と呼ばれる小さなデータのかたまりを作成して、あなたのブラウザを通じてSPへ送ります。SPはこのアサーションを受け取り、内容を検証して、承認された場合にだけサービスの利用を許します。アサーションの中身は、主に二つのタイプがあります。Authnアサーションは“この人がいつ、どの端末で、どう認証したか”といった認証情報を伝えます。Attributeアサーションは“この人の役割は何か”、“部門はどこか”といった属性情報を含めることが多いです。セキュリティを守るためには、アサーションは署名され、場合によっては暗号化されて送られます。通信はHTTPSで保護され、信頼できる証明書とメタデータの交換が前提になります。SAMLを使う利点は、パスワードを覚える数が減り、複数のサービスで統一的なログイン体験が得られる点です。一方、設定ミスや証明書の期限切れ、時刻のズレなどの運用リスクにも注意が必要です。企業や教育機関が多くのクラウドサービスを安全につなぐために、SAMLアサーションは欠かせない要素となっています。
saml 連携とは: 「saml 連携とは」について、初心者でも分かるようにやさしく解説します。SAML は Security Assertion Markup Language の略で、企業内のIDを使って、いくつものサービスに同じログイン情報でアクセスできる仕組みです。ここでの「連携」は、ログインの認証情報を一つの場所で管理して、別のアプリケーションにも安全に伝えることを意味します。SAML の基本は、三者の関係と流れです。まず利用者がサービスA（サービスプロバイダ、SP）にアクセスすると、A は利用者を認証できる窓口である IDP（認証提供者）へ案内します。次に IDP は利用者の身份を確認し、確認できたら「アサーション」という証明情報を SP に返します。SP はこのアサーションを受け取り、利用者が認証済みだと判断してサービスへのアクセスを許可します。面倒なアカウント作成を減らし、パスワードの使い回しを防げる点がメリットです。ただし導入には準備が必要で、IDPとSPの信頼関係を作ったり、証明書やメタデータの交換、時刻の同期などの設定が求められます。SAML 連携を実現することで、企業は社内の認証を一元管理しつつ、社員が複数のクラウドサービスを使いやすくすることができます。初心者の方は、まず IDP と SP の役割を覚え、次にアサーションの流れと設定上のポイントを押さえると理解が進みます。
saml フェデレーションとは: saml フェデレーションとは、インターネット上で複数のサービスを一度の認証で利用できる仕組みのことです。SAMLはSecurity Assertion Markup Languageの略で、主に企業の内部システムと外部サービスをつなぐときに使われます。フェデレーションとは信頼関係を作ることを指し、IdPとSPという二つの役割が協力します。流れはこうです。まずユーザーはIdPのログイン画面で自分の情報を入力します。IdPはその人が正しいかを確かめ、認証した証拠としてSAMLアサーションと呼ばれるデータを作ります。次にこのアサーションをブラウザを通じてSPへ渡します。SPは受け取ったアサーションを検証し、署名や有効期限が正しいかを確認します。問題がなければそのユーザーはSPのサービスに自動でログインします。
saml 2.0 とは: saml 2.0 とは、ウェブサービス同士があなたの身元を安全に伝えるための標準的な仕組みです。SAMLはSecurity Assertion Markup Languageの略で、主に企業や学校などの大きな組織で使われています。ここで登場する重要な2つの役者は、Identity Provider（IdP）とService Provider（SP）です。IdPは「あなたが誰か」を確認する窓口。学校のログイン画面のように、正しいIDとパスワードを入力して認証します。SPは実際に使いたいサービス、たとえば社内ポータルや学習アプリの提供元です。認証が終わると、IdPはSPに「アサーション」と呼ばれる証明書のようなメッセージを送ります。これには「この人は正しいIDを持っている」という情報が入っています。受け取ったSPはその情報を検証し、ユーザーにサービスへのアクセスを許可します。大きな特徴は、一度IdPでログインすれば、同じIdPを信頼する複数のSPに対して再度パスワードを入力せずにアクセスできる点です。これがSSO（シングルサインオン）と呼ばれる仕組みです。SAMLは主にWebブラウザ上のやり取りで使われ、認証のデータはXML形式で安全にやり取りされます。実装にはセキュリティの設定や信頼関係の構築が必要で、設定ミスは情報漏えいの原因になることもあります。SAMLと他の認証技術との違いも知っておくと便利です。OAuthとOpenID Connectは最近よく使われますが、OAuthは「何の権限を使えるか」を許可する仕組み、OpenID Connectは「誰がログインしたか」を特定する機能を持つ拡張です。SAMLは主に企業のWebアプリでのSSOに強く、モバイルアプリや新しいウェブAPIの連携にはOIDCが使われることが多いです。SAMLのメリットは、パスワードの使い回しを減らせる、安全な集中管理、管理者の負担軽減です。デメリットは導入と運用が複雑で、特に小さな組織では手間がかかる点です。利用シーンとしては従業員用のポータル、学習システム、社内ツールの統一的なログイン体験が挙げられます。
saml エンティティid とは: SAML（Security Assertion Markup Language）は、複数のサービスを1度のログインで使えるようにする仕組みです。たとえば学校のクラウドサービスや業務アプリを使うとき、毎回IDとパスワードを入力する代わりに、学校の認証機関（IdP）で一度認証しておけば、他のアプリ（SP）でも同じログイン状態が使えます。このとき重要になるのが「エンティティID」です。エンティティIDはSAMLの中で、IdP（Identity Provider）やSP（Service Provider）を一意に識別するための識別子です。名前だけ聞くと難しそうですが、要は「このサービスや認証機関はどこだ」という住所のようなものです。多くの場合、エンティティIDはURLの形をとることが多いですが、必ずしもURLである必要はありません。実務ではメタデータXMLという情報の中にエンティティIDが書かれており、相手方がこのIDを見て信頼できる相手かどうかを判断します。 IdPとSPの役割を分けて考えると分かりやすいです。IdPのエンティティIDは「あなたを認証する機関のID」、SPのエンティティIDは「あなたが利用するサービスのID」です。SAMLのやり取りでは、IdPが発行するトークン（アサーション）にIdPのエンティティIDが“発行者（Issuer）”として含まれ、SPが受け取るアサーションには受け取り側のエンティティIDが“Audience（観客）”として使われます。つまりエンティティIDは信頼の基盤であり、メタデータの更新や値の変更には注意が必要です。設定ミスがあると、認証がうまくいかなかったり、相手を誤って信頼してしまうリスクがあります。もし自分の組織でSAMLを使う場合は、 IdPとSPそれぞれに一意のエンティティIDを設定し、相手側のメタデータと照合できる状態を作ることが大切です。エンティティIDは長期にわたり安定して利用することが多いため、変更時には周知と再設定を忘れずに行いましょう。基本的な理解としては「エンティティIDは誰が、どこにいるのかを識別するための住所」であり、SAMLの信頼構築の第一歩です。
ruby-saml とは: ruby-saml とは、Ruby 言語で動くウェブアプリが SAML 2.0 という認証の仕組みを使えるようにするライブラリです。SAML は、サービス提供者（SP）とアイデンティティプロバイダ（IdP）の間で、ログインの情報を安全にやり取りするための国際的な標準規格です。これを使うと、あるサイトにログインする時に毎回別のアカウントを作ったり、パスワードを覚えたりする必要が減り、ひとつの IdP で認証すれば他のサービスにも同じ名前で入れることができます。ruby-saml は OneLogin が提供する Ruby の gem で、SAML のリクエストを作成する機能、IdP から返ってくる SAML Response の検証と署名チェック、属性（名前、メールアドレス、役職など）の取得を手助けします。Rails や Sinatra などの Ruby フレームワークと組み合わせて、設定ファイルに IdP のエンドポイントや公開証明書、返される属性名を書くだけで使い始められます。使い方のざっくりした流れは次の4ステップです。1) SP がユーザーの認証を求めると、ruby-saml を使って SAML AuthnRequest を生成し、IdP へ転送します。2) IdP がそのユーザーを認証し、証明済みの SAML Response を SP に返します。3) SP は受け取った SAML Response を ruby-saml で検証し、署名が正しいか、時刻が有効か、リクエストと整合しているかを確認します。4) すべてOK ならアプリ内でそのユーザーをログイン状態にします。注意点として、証明書の管理、時刻の同期（時刻のズレ）、IdP 側の設定変更時の影響などがあります。実運用では、テスト用 IdP を用意して段階的に導入するのがおすすめです。
node-saml とは: node-saml とは、Node.js アプリケーションで SAML 2.0 認証を実装するためのライブラリです。SAML は、組織が複数のアプリを一度のログインで使えるようにする「シングルサインオン（SSO）」の仕組みで、ユーザーは一度の認証情報で信頼されたサービスへアクセスできます。node-saml を使うと、サービスプロバイダ（SP）としての機能と、アイデンティティプロバイダ（IdP）とのやりとりを、複雑な署名・検証・メタデータの処理をライブラリに任せられます。具体的には、SP 側の設定で IdP のメタデータや証明書を登録し、ログイン要求（AuthnRequest）を IdP に送る、IdP から返される SAML Response を受け取り、署名検証と検証済みの属性情報をアプリのセッションとして保存する、という流れになります。導入する時には、TLS の通信は当然の前提で、 IdP 側のメタデータの更新や証明書のローテーションにも対応できるよう、設定を管理することが大切です。node-saml は Express などの Node.js フレームワークと組み合わせて使われることが多く、ルーティングの中で /login や /acs（アサーション消費サービス）といったエンドポイントを用意して、ユーザーのログインフローを実装します。注意点としては、SAML は比較的設定が難しく、証明書の有効期限切れや時刻のずれによる検証エラーが起きやすい点です。さらに、現代のウェブでは OAuth2/OIDC がよく使われますが、組織の既存 IdP やセキュリティ要件に合わせて SAML を選ぶケースもあります。導入前には IdP の対応状況や、SP 側のメタデータの作成方法、証明書管理、そしてユーザー情報の属性（名前、メール、部署など）の取り扱い方を整理しておくとよいでしょう。
aws saml とは: aws saml とは、SAMLという仕組みを利用して、AWS（アマゾン（関連記事：アマゾンの激安セール情報まとめ）ウェブサービス）に安全にログインする仕組みのことです。SAMLは「Security Assertion Markup Language」の頭文字をとった、IDプロバイダーとサービス提供者が認証情報をやり取りする国際的な規格です。aws saml とは、SAML 2.0規格を使って、企業のIDプロバイダー（例：Okta、Azure AD、Google Workspace など）とAWSを結びつけ、社員が一度のログインでAWSのアクセス権を得られるようにする仕組みを指します。具体的には、IdP側でユーザーが認証されると、SAMLアサーションと呼ばれる証明書のような情報がAWSに渡されます。AWS側はこのアサーションを検証して、temporary credentials（期限付きの認証情報）を発行します。これにより、個別のアカウントとパスワードをAWS側で管理せずに済み、セキュリティと管理の負担が減ります。設定には、AWS側にSAMLプロバイダの登録、信頼関係（ロールとSAMLの信頼ポリシー）の作成、IdP側にはアプリケーション設定とユーザーの属性（どのグループの人がどの権限を持つか）を決める作業が必要です。注意点として、SAMLは認証と認可を連携させる仕組みなので、IdPのセキュリティが悪いと全員が不正アクセスできてしまうリスクがあります。最近は「AWS IAM Identity Center（旧 AWS SSO）」を使って、SAMLを使わずとも簡単に一括管理できる選択肢もあります。初心者には、まずIdPの基本とSAMLの流れ、次にAWS側の信頼関係の作り方を順を追って練習すると理解が深まります。

samlの同意語

SAML: Security Assertion Markup Languageの略称。XMLを用いてアイデンティティ情報をやり取りし、シングルサインオン（SSO）を実現する標準プロトコルです。
セキュリティアサーションマークアップランゲージ: SAMLの正式名称の日本語表記。アイデンティティ情報をアサーションとしてXMLで表現・伝達することを規定した認証・認可の標準規格です。
Security Assertion Markup Language: SAMLの正式名称（英語表記）。アイデンティティ情報を安全に伝えるためのXMLベースの規格です。
SAML 2.0: SAMLの主要な現行バージョン。証明情報のやり取りやSSOを安定して実現するための改良点を含む規格です。
SAML認証: SAMLを使った認証のこと。IdPが身元を証明し、SPがアクセス許可を判断する仕組みを指します。
SAMLベースの認証: SAMLを核にした認証の総称。複数の組織間でのアイデンティティ連携を前提とした仕組みです。
フェデレーション認証プロトコル: 異なる組織間でアイデンティティ情報を連携して認証を実現するプロトコルの総称。SAMLはその代表的な規格のひとつです。

samlの対義語・反対語

ローカル認証: 外部のアイデンティティプロバイダを介さず、アプリ内のユーザー情報を直接照合する認証方式。SAMLのフェデレーション機能を使わない点が対比的です。
スタンドアロン認証: 単一のアプリケーション内で完結する認証。SSO（シングルサインオン）や他サービスとの連携を前提としません。
フォームベース認証: ウェブのログインフォームでユーザー名とパスワードを直接入力して認証する、従来型の認証方法。
ベーシック認証: HTTPの基本認証で、ユーザー名とパスワードをHTTPヘッダー経由で送信して認証する方法。外部IdPを使わず、SAMLとは異なる仕組みです。
OIDC認証: OpenID Connectを用いた認証。SAMLとは別のID連携プロトコルで、トークンベースの認証が主流です。
JWT認証: JWT（JSON Web Token）を用いたトークンベースの認証・認可。SAMLのXMLアサーションとは異なる設計です。
OAuth 2.0認可連携: OAuth 2.0は主に認可（アクセス許可）の仕組みであり、認証を前提とするSAMLの代替として使われるケースは限定的です。
非SSO型認証: SSOを利用せず、各サービスごとに個別に認証を行う方式。

samlの共起語

SAML: Security Assertion Markup Language の略。XMLベースの認証情報と属性を交換する標準的な認証認可プロトコル。
SSO: Single Sign-On の略。1度のログインで複数のサービスにアクセスできる仕組み。
IdP: Identity Provider の略。ユーザーを認証して認証情報を発行する機関。
SP: Service Provider の略。IdP からの認証結果を受け取り、サービスへのアクセスを許可する側。
Assertion: SAML アサーション。認証結果と属性情報を含む XML 文書の断片。
NameID: NameID はユーザーを一意に識別する識別子。
Issuer: アサーションの発行者。通常 IdP のエンティティID。
Audience: アサーションの受け手の識別子。通常は SP のエンティティID。
RelayState: リダイレクトなどの際に元のリクエスト状態を保持する値。
AuthnRequest: 認証要求メッセージ。SP から IdP へ送る XML。
Response: IdP から SP への認証応答。認証結果と属性が含まれる。
ACS: Assertion Consumer Service。SP 側のアサーション受信エンドポイント。
Metadata: SAML メタデータ。IdP と SP の設定情報を記述する XML。
SAML 2.0: SAML の第2世代仕様。現在の主流バージョン。
Binding: SAML メッセージの伝送モード。HTTP Redirect、HTTP POST、Artifact など。
POST Binding: アサーションを HTTP POST で送る伝送モード。
Redirect Binding: アサーションを HTTP Redirect で送る伝送モード。
Artifact Binding: アサーション取得を Artifact 参照を介して行う伝送モード。
XML: 拡張可能マークアップ言語。SAML は XML ベースの仕様。
XML Signature: XML 文書に署名を付ける仕組み。改ざん検知と信頼性を確保。
X.509: 公開鍵証明書の標準。署名・暗号化で使われる。
Certificate: 公開鍵証明書。署名・暗号化に使われるデータ。
AttributeStatement: アサーション内の属性情報の集まり。
Attribute: 個々の属性。例: email、役割、部署など。
AuthenticationContext: 認証文脈。どの認証が使われたかの情報。
AuthnContextClassRef: 要求される認証クラスの参照。例: PasswordProtectedTransport など。
EntityDescriptor: SAML メタデータのエンティティ記述要素。
SPSSODescriptor: SP 側の SSO 設定を記述するメタデータ要素。
IDPSSODescriptor: IdP 側の SSO 設定を記述するメタデータ要素。
Federation: アイデンティティの連携・フェデレーション。
Trust: 信頼関係。IdPとSPが相互に信頼する前提。
SLO: Single Logout の略。1つのログアウトで複数セッションを終了。
SPInitiatedSSO: SP 側から開始して IdP による認証を得る SSO の流れ。
IdPInitiatedSSO: IdP 側から開始してSPへ認証情報を返す流れ。
NameFormat: NameID の形式。例: persistent、emailAddress、unspecified。
AudienceRestriction: アサーションの対象制約。SP のエンティティID が一致する必要。
Conditions: アサーションの適用条件（有効期間、発行者条件、オーディエンスなど）。
SubjectConfirmation: アサーションの対象確認条件。Recipient、NotOnOrAfter などを含む。
EntityID: エンティティの一意識別子。IdP/SP の識別子として使用。
NameIDFormat: NameID の表現形式の種類。persistent、emailAddress、unspecified。

samlの関連用語

SAML: Security Assertion Markup Language（XMLベースの認証・承認データ交換規格）。IdPとSPの間でユーザーの認証状態や属性情報を安全に伝える仕組みです。
SAML 2.0: 現在の標準バージョン。署名・暗号化・メタデータ交換、様々なバインディングに対応したWebブラウザSSOの基盤。
IdP: Identity Provider（認証機関）。ユーザーを認証し、認証情報と属性をSPへ渡します。
SP: Service Provider（サービス提供者）。IdPから受け取った認証情報を使ってユーザーにリソースアクセスを許可します。
Assertion: IdPが発行するXML形式の認証情報の塊。認証結果と属性情報を含みます。
Subject: アサーションの対象となるユーザー（主体）。
Issuer: アサーションを発行したエンティティ（通常はIdPの識別子）。
NameID: ユーザーを識別する一意の識別子。SPが受け取ることが多い情報。
NameIDFormat: NameIDの表現形式を規定するフォーマット。例：persistent、transient、emailAddress、entity。
AttributeStatement: アサーション内の属性情報を格納するセクション。
Attribute: 属性データ。例：メール、部署、権限など。
AttributeNameFormat: 属性名の格式を示す規約。例：unspecified、nameFormatなど。
AudienceRestriction: このアサーションを受け取ってよいSPを制限する条件。
Audience: このアサーションを受信してよい対象（SP）の識別子。
Recipient: アサーションの受領者。通常はSPのACSエンドポイント。
AssertionConsumerService: SP側でアサーションを受け取り処理するエンドポイント。
AssertionConsumerServiceURL: ACSの実際のURL。
SingleSignOn: 一度の認証で複数のサービスへ自動的にログインさせる仕組み。
SingleLogout: 一度のログアウトで関係するサービスも同時にログアウトさせる仕組み。
Binding: SAML情報を転送する伝送方法の総称。
HTTPRedirectBinding: URLのクエリ文字列でデータを転送するバインディング。
HTTPPostBinding: HTMLフォームを用いてデータを送信するバインディング。
ArtifactBinding: アーティファクトと呼ばれる短い識別子を介してバックチャネルでデータを取得するバインディング。
SOAPBinding: SOAPを使ったバックエンド通信のバインディング（主にArtifact Resolutionなどで使用）。
WebBrowserSSOProfile: ブラウザを介したSSOを前提とした標準プロファイル。
ECPProfile: Enhanced Client or Proxyプロファイル。非ブラウザ向けのSSO対応。
Metadata: IdPとSPの設定情報を含むXML。エンドポイント、証明書、EntityIDなどを記述。
IdPMetadata: IdPのメタデータ。公開鍵証明書・エンドポイント情報を含む。
SPMetadata: SPのメタデータ。公開鍵証明書・エンドポイント情報を含む。
MetadataURL: メタデータの取得先URL。
EntityID: IdPまたはSPを一意に識別する識別子（通常はURL風のID）。
RelayState: 複数のSP間で状態情報を保持するための値。主にHTTPフローで使用。
Artifact: ArtifactBindingで用いられる短い識別子。バックチャネルでアサーションを取得する際に使用。
ArtifactResolutionService: Artifactを用いてアサーションを取得するためのエンドポイント。
Signature: XML署名。アサーションやメタデータの改ざん防止に用いられます。
XML Signature: XMLデータの署名に関する標準仕様。
Encryption: アサーションや属性情報を暗号化して機密性を確保します。
XML Encryption: XMLデータを暗号化する仕様。
X509Certificate: 公開鍵証明書。署名・暗号化に用いられます。
PKI: Public Key Infrastructure。証明書の発行・検証・信頼の枠組み。
Conditions: アサーションの有効条件を定義する要素。
NotBefore: アサーションが有効になる時刻。
NotOnOrAfter: アサーションが無効になる時刻。
SubjectConfirmation: アサーションの対象者を確認する手段（Recipient・NotBefore/NotOnOrAfter等を含む）。
AuthnStatement: 認証時刻・認証情報を表す要素。
AuthnInstant: ユーザーが認証を実行した時刻。
SessionIndex: 認証セッションの識別子。
AuthnContext: 認証時の文脈情報（どの認証方法を使ったかなど）。
AuthenticationContextClassRef: 認証クラスの参照。認証の強度・方法を示す。
SPInitiatedSSO: SP側からSSOを開始する方式。
IdPInitiatedSSO: IdP側からSSOを開始してSPへ認証情報を渡す方式。
Federation: 複数組織間での信頼関係と認証情報の共有を指す概念。
Trust: IdPとSPの間の信頼を築く設定・検証プロセス。
NameIDPolicy: IdPに対して要求するNameIDの形式や属性のポリシーを指定。
LogoutRequest: SLOの一部。SPへログアウトを通知するリクエスト。
LogoutResponse: SLOの応答メッセージ。ログアウトの完了を通知。