SAMLとは何か？SSOを支える認証技術の仕組みをゼロから解説

知識

「Microsoft 365にもログインしたいし、Salesforceにもログインしたい。でもパスワードを何個も覚えるのは面倒」——こうした課題を解決するのがシングルサインオン（SSO）であり、その中心にある技術がSAML（サムル）です。

本記事では、認証技術の基礎を学びたい方・クラウド／SaaS導入に関わる方・IT系資格学習者を対象に、以下の内容を解説します。

  • SAMLが何のために生まれた技術か
  • IdP・SP・アサーションといった用語の意味
  • ユーザーがログインするときの内部の流れ
  • OIDC・OAuth 2.0との違いと使い分け
  • SAMLが使われている代表的なシーン
  • AWSへのアクセスをSAMLで実現する具体的な方法


なぜSAMLが必要なのか

クラウドサービスが普及した結果、現代の企業ではひとりの社員が利用するサービスが10個以上にのぼることも珍しくありません。Microsoft 365・Salesforce・Slack・AWS・社内勤怠システム・経費精算システム——もし全てのサービスで個別にIDとパスワードを管理しなければならないとしたら、どうなるでしょうか。

個別管理には主に3つの問題があります。

第一に、ユーザーが大量のパスワードを覚えきれないという負担が発生します。結果として簡単なパスワードを使い回したり、付箋に書き留めたりするなどのセキュリティリスクにつながります。

第二に、社員の退職や異動の際の権限管理が極めて煩雑になります。退職者のアカウントを、利用しているすべてのサービスから個別に削除しなければならず、漏れがあれば不正アクセスのリスクとなります。

第三に、監査対応が困難になります。「誰が、いつ、何にアクセスしたか」をシステムごとに別々のログから集めて整理する必要があり、コストが膨らみます。

こうした課題を一気に解決するのがシングルサインオン（SSO）という考え方であり、SAMLはその実現を支える代表的な認証プロトコルです。


SAMLとは何か

SAML（Security Assertion Markup Language／サムル）とは、異なるシステム間でユーザーの認証情報を安全にやり取りするための、XMLベースの標準プロトコルです。読み方は「サムル」または「エスエーエムエル」と呼ばれます。

2005年に標準化団体 OASIS（オアシス）によって SAML 2.0 が策定されて以来、企業向けクラウドサービスのSSO実装で事実上の標準として広く使われています。

ポイント：SAMLは「認証」と「認可」の両方を扱う
「あなたが誰か（認証）」だけでなく「あなたが何をしてよいか（認可）」も同時に伝えられるのが、SAMLの大きな特徴です。例えば「このユーザーは確かに田中さんで、しかも管理者権限を持っている」という情報を、1つのメッセージにまとめて運べます。

SAMLの仕組みを理解するうえで、まず押さえておきたいのは「認証する場所」と「サービスを使う場所」を分けるという思想です。社内のID管理サーバーで認証を済ませ、その結果を信頼できる形で各サービスに伝える——この役割分担を実現するのがSAMLの目的です。


登場人物：IdPとSPとユーザー

SAMLの世界には、3人の主要な登場人物がいます。

登場人物正式名称役割具体例
ユーザーPrincipalサービスを使いたい人社員・取引先
IdPIdentity Providerユーザーを認証する側Active Directory、Okta、OneLogin
SPService Providerサービスを提供する側Microsoft 365、Salesforce、AWS

ユーザー（プリンシパル）は、サービスを使いたい人間です。SAMLの興味深いところは、IdPとSPがブラウザを介してやり取りする設計になっており、SPとIdPが直接通信する必要がないため、社内サーバー（IdP）と社外SaaS（SP）の間にネットワーク的な接続を確立しなくてもSSOが実現できる点です。

IdP（アイデンティティプロバイダー）は、ユーザーを認証する役割を担います。「この人は確かに弊社の田中さんですよ」と証明書を発行する立場、と覚えるとわかりやすいでしょう。

SP（サービスプロバイダー）は、実際にサービスを提供する側です。SPはIdPから受け取った認証情報を信頼してユーザーを受け入れる、という関係になっています。


SAML認証の流れ

実際にユーザーがログインするときに、内部で何が起きているのでしょうか。最も基本的な流れであるSP-initiated SSO（SPを起点とするパターン）を見てみます。

  1. ユーザーがブラウザでサービス（SP）にアクセスする
  2. SPは「未認証」と判断し、SAML認証要求（AuthnRequest）を発行する
  3. AuthnRequestはユーザーのブラウザを経由してIdPへ届けられる
  4. IdPはユーザーにログイン画面を提示する
  5. ユーザーがIDとパスワードを入力・送信する
  6. 認証成功後、IdPがSAMLアサーションを発行しブラウザへ返す
  7. ユーザーのブラウザがアサーションをSPに提出する
  8. SPがアサーションを検証し、問題なければサービス画面を表示する

SPとIdPは直接通信しない
SPとIdPがやり取りする情報はすべてユーザーのブラウザ経由で運ばれます。これにより、社内のIdPとインターネット上のSPがネットワーク的に直接接続できない環境でも、SSOが成立する設計になっています。


SAMLアサーションの中身

SAMLの心臓部とも言えるのがSAMLアサーションです。これは「IdPが署名した、ユーザーに関する電子的な証明書」のようなもので、XML形式で記述されています。

要素内容用途
Issuer発行者（IdP）の識別子誰が発行したか
Subjectユーザーの識別情報認証情報
Conditions有効期限・対象SP等いつまで・どこで使えるか
AttributeStatement属性情報（部署・権限）認可情報
SignatureIdPの電子署名改ざんされていない証明

イメージしやすいよう、簡略化したSAMLアサーションのXMLを示します。

<saml:Assertion Version="2.0" IssueInstant="2025-04-27T10:00:00Z">
  <saml:Issuer>https://idp.example.com</saml:Issuer>

  <saml:Subject>
    <saml:NameID>tanaka@example.com</saml:NameID>
  </saml:Subject>

  <saml:Conditions
      NotBefore="2025-04-27T10:00:00Z"
      NotOnOrAfter="2025-04-27T11:00:00Z">
  </saml:Conditions>

  <saml:AttributeStatement>
    <saml:Attribute Name="Department">
      <saml:AttributeValue>営業部</saml:AttributeValue>
    </saml:Attribute>
    <saml:Attribute Name="Role">
      <saml:AttributeValue>Administrator</saml:AttributeValue>
    </saml:Attribute>
  </saml:AttributeStatement>

  <ds:Signature>...IdPによる電子署名...</ds:Signature>
</saml:Assertion>

このXMLには「tanaka@example.com というユーザーが、営業部の管理者として、1時間有効な形で認証されました」という情報が記述されています。SPはこれを受け取って内容を確認し、署名が正しいことを検証したうえで、ユーザーに適切な権限を付与します。

電子署名がセキュリティの要
アサーションにはIdPの秘密鍵による電子署名が付与されています。SPは事前にIdPの公開鍵を持っているので、署名を検証することで「本物のIdPが発行したアサーションで、改ざんされていない」ことを確認できます。これがSAMLの安全性を支える根幹の仕組みです。


空港の入国審査で例えると

SAMLの仕組みは、海外旅行のパスポート審査によく似ています。

SAMLの世界海外旅行で例えると
ユーザー旅行者
IdP（社内認証サーバー）パスポートを発行する自国の役所
SP（クラウドサービス）渡航先の国の入国審査
SAMLアサーションパスポートおよび査証（ビザ）
IdPによる署名役所による偽造防止印・ホログラム
事前のメタデータ交換国家間の外交関係の樹立

日本から米国に行くとき、まず日本の役所（IdP）でパスポート（アサーション）を発行してもらいます。米国の入国審査官（SP）はあなた個人を知らなくても、日本政府の発行物だと信頼できるパスポートを見れば「この人は確かに田中さんで、観光目的で90日まで滞在できる」と判断できます。

このとき、米国の入国審査官は日本の役所と直接やり取りはせず、あなたが持参したパスポート（旅行者＝ブラウザが運ぶ）だけを見て判断するのがポイントです。これが「SPとIdPは直接通信しない」というSAMLの設計思想と一致しています。


OIDC・OAuth 2.0との違い

SAMLと並んで、認証・認可の文脈でよく登場するのがOpenID Connect（OIDC）とOAuth 2.0です。これらは似ているようで、実は役割が異なります。

項目SAML 2.0OAuth 2.0OpenID Connect
主な目的認証＋認可認可のみ認証＋認可
策定時期2005年2012年2014年
データ形式XML（重い）トークンJWT/JSON（軽い）
主な用途企業内SSOAPI権限委譲モバイル/Webログイン
得意な領域エンタープライズサービス間連携コンシューマー向け
代表例M365/AWS管理者SNS連携投稿Googleでログイン

OAuth 2.0は名前に「Auth」とついていますが、これは Authorization（認可）の意味で、Authentication（認証）ではありません。OAuth 2.0は「あなたが誰か」を確認する用途には使えず、あくまで「アプリケーションに、ユーザーの代わりに特定の操作を実行する権限を委譲する」ためのプロトコルです。

例えば「Googleドライブの写真をアプリに編集させたい」というケースでは、OAuth 2.0を使うことで「このアプリに写真の読み書き権限だけを与える」というアクセストークンを発行できます。アプリはそのトークンを使って写真にだけアクセスでき、メールやカレンダーなど他のデータには触れられません。

OpenID Connect（OIDC）はOAuth 2.0の上に認証機能を加えたものです。JSONベースの軽量なフォーマット（JWT）を採用しており、モバイルアプリやモダンなWebアプリでの実装が容易です。「Googleでログイン」「Facebookでログイン」「Appleでサインイン」といった機能は、ほぼすべてOIDCで実装されています。

用途別の選び方をまとめると以下のとおりです。

  • 社員が業務で使うクラウドサービスのSSO → SAML（実績豊富、Active Directory連携が確立）
  • 一般消費者向けのアプリでソーシャルログインを実装 → OIDC（軽量で開発容易）
  • サービス間でAPI権限を委譲したい → OAuth 2.0（認可専用）


SAMLが使われている場面

SAMLは現代のクラウド時代において、私たちの目に見えないところで広く活躍しています。代表的な利用シーンを見てみます。

企業のSaaS統合では、社員が業務で使うクラウドサービスを1つの社内IDで束ねます。社員はまず社内ポータルにログインし、そこからMicrosoft 365・Salesforce・Slack・AWSへ追加のログインなしでアクセスできます。退職者が出た場合は社内IDを停止するだけで、すべての関連サービスへのアクセスが一括で遮断されます。

クラウドインフラの管理者ログインでは、AWS・Google Cloud・Azureといった主要クラウドプラットフォームの管理コンソールへのログインにSAMLを使うのが推奨されています。クラウドサービス側に個別のIDアカウントを作る必要がなく、社内のID管理サーバーから直接ログインできるため、認証情報の流出リスクを最小化できます。

業界横断のフェデレーションとして、大学間で講義やリソースを共有する学術認証フェデレーション（学認）や、医療機関同士のシステム連携など、組織を超えた信頼関係を構築する場面でもSAMLが採用されています。

IT資格試験では、AWS認定ソリューションアーキテクト・プロフェッショナル（SAP-C02）をはじめとする上位資格でも頻出のトピックです。クラウドにおけるアイデンティティ管理の中核技術として、ITインフラやセキュリティに関わるエンジニアにとって必須の知識といえるでしょう。


実例：AWSへのアクセスをSAMLで実現する

ここからは、SAMLが実際にどう活用されるかを、AWSへのアクセスという具体例で深掘りします。多くの企業がAWSを業務利用しており、その認証基盤としてSAMLは事実上の標準です。

なぜAWSでSAMLを使うのか

企業がAWSを利用するとき、社員ごとにIAMユーザー（AWS内に作る個別アカウント）を発行する方法は推奨されていません。社内ID管理との二重管理になるためです。社員が退職するたびにAWS側でもアカウントを削除する必要があり、漏れがあれば不正アクセスのリスクとなります。

SAMLフェデレーションを使えば、AWS側にIAMユーザーを作らずに済みます。社員は社内のID管理サーバー（IdP）でいつも通りログインするだけで、AWS側の権限を一時的に借りる形でアクセスできます。

重要：IAMユーザーではなくIAMロール
SAMLフェデレーションでAWSにアクセスする際、ユーザーはIAMロールを「引き受ける（Assume）」という形になります。IAMロールとは「一時的に借りる権限のセット」のことで、永続的なIAMユーザーとは異なる概念です。SAMLの世界では、IAMユーザーは登場しません。

AWSにおける登場人物の整理

SAMLの一般用語AWSでの具体例役割
IdPAD、Okta、OneLogin、Azure AD社員を認証する社内ID管理サーバー
SAMLプロバイダー（IAMの設定）IAM内の saml-provider/MyIdP「このIdPを信頼する」とAWSに登録した参照エントリ
SPAWS（マネジメントコンソール／API）サービス提供側
引き受け対象IAMロール（信頼ポリシー付）AWS内の権限セット
権限引き受けAPIsts:AssumeRoleWithSAMLSAMLアサーションでロールを引き受けるAPI

「IdP」と「SAMLプロバイダー」は同じものではない
IdPは認証を提供するシステム本体（Active Directory等の実体）であるのに対し、SAMLプロバイダーはAWS側に登録したIdP参照エントリです。SAMLプロバイダーには arn:aws:iam::123:saml-provider/MyIdP のようなARNが付与され、IAMロールの信頼ポリシーで参照されます。

AWSにおけるSAML認証の流れ

  1. 社員が社内ポータルにアクセスする
  2. ポータルがIdPへ転送する
  3. IdPがID／パスワードを要求する
  4. 社員がID／パスワードを送信する
  5. 認証OK後、IdPがSAMLアサーション（IAMロールのARNを含む）を発行する
  6. ポータルがAWS STS に対して AssumeRoleWithSAML を呼び出す
  7. STSが検証OKとなり、一時クレデンシャルを発行・コンソール画面が表示される

鍵となる3つの設定要素

AWSでSAMLフェデレーションを構成するうえで、抑えるべき設定は以下の3つです。これらが正しく揃っていないと認証はうまく通りません。

① IAMロールの信頼ポリシー
IAMロールには 「誰がこのロールを引き受けてよいか」を定義した信頼ポリシー を設定します。SAMLフェデレーションの場合、「特定のSAMLプロバイダー経由で来たユーザーだけ引き受け可能」と書きます。

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Principal": {
        "Federated": "arn:aws:iam::123456789012:saml-provider/MyCompanyIdP"
      },
      "Action": "sts:AssumeRoleWithSAML",
      "Condition": {
        "StringEquals": {
          "SAML:aud": "https://signin.aws.amazon.com/saml"
        }
      }
    }
  ]
}

注目すべき要素は3つあります。Principalには SAMLプロバイダーのARN を指定し、Actionには sts:AssumeRoleWithSAML（SAML経由でロールを引き受けるための専用アクション）を指定し、ConditionでAWSサインインエンドポイントが意図したものであることを確認します。

② SAMLアサーションへのIAMロール属性の埋め込み
IdPが発行するSAMLアサーションには、「このユーザーが引き受けてよいIAMロールのARN」 を属性として含めます。AWSが定義する専用の属性名 https://aws.amazon.com/SAML/Attributes/Role を使うのがルールです。

<saml:Attribute Name="https://aws.amazon.com/SAML/Attributes/Role">
  <saml:AttributeValue>
    arn:aws:iam::123456789012:role/Developer,
    arn:aws:iam::123456789012:saml-provider/MyCompanyIdP
  </saml:AttributeValue>
</saml:Attribute>

カンマ区切りで 「IAMロールのARN」と「SAMLプロバイダーのARN」のペア を記述します。複数のロールを引き受け可能にするときは、このAttributeValueを複数記述します。例えば「Developer」「Administrator」「ReadOnly」の3つを許可しておけば、社員はログイン後にロール選択画面でどれかを選んで使うことができます。

③ AssumeRoleWithSAML APIの呼び出し
社内ポータル（または社員のブラウザ経由）から、AWSのSTSサービスに対して AssumeRoleWithSAML APIを呼び出します。これは 「このSAMLアサーションを根拠に、このロールを引き受けたい」 とAWSへ要求するものです。

aws sts assume-role-with-saml \
  --role-arn arn:aws:iam::123456789012:role/Developer \
  --principal-arn arn:aws:iam::123456789012:saml-provider/MyCompanyIdP \
  --saml-assertion file://assertion-base64.txt

呼び出しが成功すると、AWSは 一時的なアクセスキー（AccessKeyId、SecretAccessKey、SessionToken）を返します。これを使ってAWSのリソース操作が可能になります。デフォルトの有効期限は1時間で、最大12時間まで延長できます。

AWS SAMLフェデレーション構築の全体像

実際にゼロからAWSとSAMLを連携する手順は、おおむね以下の流れです。

よくあるトラブルと確認ポイント

SAMLフェデレーション構築では、設定が一つでもズレるとログインできない事態が起きます。代表的なトラブルパターンを押さえておきましょう。

症状疑うべき原因確認場所
特定ユーザーだけアクセス拒否されるそのユーザーがIAMロールにマッピングされていないIdP側のSAMLアサーション属性設定
「ロールを引き受けられない」エラー信頼ポリシーがそのSAMLプロバイダーを許可していないIAMロールの信頼ポリシー
署名検証エラーIdPの証明書が期限切れ・更新されていないSAMLプロバイダーのメタデータ
セッションがすぐ切れるセッション有効期間が短く設定されているIAMロールの最大セッション期間設定

トラブル時の3つのチェックポイント
SAMLフェデレーションがうまく動かないとき、優先的に確認すべきは以下の3点です。一つ目は IAMロールの信頼ポリシー（SAMLプロバイダーがプリンシパルとして指定されているか）、二つ目は SAMLアサーションのRole属性（IAMロールARNがマッピングされているか）、三つ目は AssumeRoleWithSAML APIの呼び出し（必要なパラメータが揃っているか）です。AWS認定試験でも、この3点に関する問題は頻出します。

IAM Identity Centerという選択肢

近年、AWSでは IAM Identity Center（旧AWS SSO） という新しいフェデレーションサービスが推奨されています。これは マルチアカウント環境のSSOを大幅に簡素化 するサービスで、組織内の複数AWSアカウントを横断したアクセス管理を一元化できます。

IAM Identity Centerは内部でSAMLを利用しているため、本記事で学んだSAMLの知識はそのまま活きます。さらに、Active DirectoryやOktaといった外部IdPとの連携も標準でサポートされており、IAMロールの信頼ポリシーやアサーション属性を手動で書く手間が大幅に削減されます。

新規にAWSフェデレーション環境を構築する場合は、まず IAM Identity Centerの利用を検討することをおすすめします。一方、既存の構成を理解したり、既存のSAMLフェデレーションをトラブルシュートしたりする場合は、本記事で説明した 素のIAM SAMLフェデレーションの仕組み を理解しておくことが必要です。


まとめ

この記事のポイント

  • SAMLは、異なるシステム間でユーザーの認証情報を安全にやり取りするための、XMLベースの標準プロトコルである
  • 登場人物は3者：ユーザー・IdP（認証する側）・SP（サービス提供側）
  • SPとIdPは直接通信せず、ユーザーのブラウザを介してSAMLアサーションが運ばれる
  • アサーションはIdPの電子署名で守られており、改ざんを検出できる
  • SAMLは認証と認可の両方を扱える点が特徴で、エンタープライズ用途で広く採用されている
  • OIDCはモダンな代替プロトコル、OAuth 2.0は認可専用で、用途に応じて使い分ける
  • AWSにアクセスする場合はIAMロールを引き受ける形となり、IAMユーザーは作らない。鍵となる設定は 「信頼ポリシー」「Role属性のマッピング」「AssumeRoleWithSAMLの呼び出し」の3つ

SAMLはやや古い技術と思われがちですが、企業向けのSSOにおいては今も 事実上の標準 として確固たる地位を占めています。クラウドサービスを業務で活用するうえで、IT技術者として理解しておくべき基礎知識のひとつです。

本記事の内容を入り口として、より深い領域——例えばIAMロールとSAMLの連携、IdPの実装方式、ゼロトラストアーキテクチャにおけるSAMLの役割など——に興味を広げていただければ幸いです。


参考リソース

コメント

タイトルとURLをコピーしました