1
0

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?

はじめに

近年はクラウドサービスやWebアプリケーションを複数利用する企業が増え、
一度のログインで複数のサービスを利用できる「シングルサインオン(SSO)」 の重要性が高まっています。

その代表的な仕組みのひとつが SAML認証 です。
SAMLはXMLベースの標準仕様で、異なるシステム間でも安全に認証情報や属性情報をやり取りできます。
例えば、社内ポータルにログインするだけで、SalesforceやGoogle Workspaceなどのクラウドサービスにも自動的にアクセスできるようになります。

この記事では、SAML認証の仕組みや認証の流れをわかりやすく解説し、
あわせて公開鍵証明書やメタデータの役割、鍵管理のポイント、そして実務上の注意点についても触れます。
※応用情報技術者試験の午前問題に登場した内容の理解を深めるための備忘録です。

1. SAML認証とは

SAML(Security Assertion Markup Language)は、XML形式で認証や認可(権限)に関する情報を交換するための標準仕様です。
特にSSOの実現によく利用され、ユーザーは一度ログインするだけで、複数のサービスにシームレスにアクセスできます。
また、SAMLアサーションにはユーザーの属性情報(氏名、メールアドレス、役職、所属部署など)も含められるため、SP側でアクセス制御に活用できます。

2. 関係者(3者モデル)

SAML認証は、以下の3者が連携して動作します。

役割 説明
ユーザー(Principal) サービスを利用する本人
サービスプロバイダ(SP) ユーザーが利用したいアプリやサービス(例:Salesforce)
アイデンティティプロバイダ(IdP) 認証を行うサーバー(例:Okta, Azure AD, ADFS)

3. 認証の流れ

SAML認証には大きく分けて2つの方式があります。

  • SP Initiated SSO:ユーザーがまずSPにアクセスしてからIdPにリダイレクトされる方式(一般的)
  • IdP Initiated SSO:ユーザーがIdPから直接SPにログインする方式(社内ポータルから各サービスへ遷移するケースなど)

以下では、より利用頻度の高い SP Initiated SSO の流れを解説します。

1. ユーザーがSPにアクセス

ユーザーが直接SP(例:Salesforce)のURLを開くと、SPは「このユーザーが誰なのか」を判断できないため、認証を要求します。

2. SPがIdPへリダイレクト

SPは認証処理をIdPに委ねるため、ブラウザをIdPの認証ページにリダイレクトします。
このとき SAMLのAuthnRequestメッセージ を送信し、どのSPからのリクエストなのか、レスポンスの返却先などを伝えます。
実装ではHTTP-Redirect(GET)方式で送られることが多いです。

3. IdPがユーザー認証

IdPはログイン画面を表示し、ユーザー名・パスワードやワンタイムコードで本人確認を行います。
認証に成功すると、IdPは「このユーザーは正当な本人である」という証明を作成します。

4. IdPがSAMLアサーション発行

認証結果やユーザー属性を SAMLアサーション にまとめ、IdPの秘密鍵でデジタル署名します。
SPは事前に受け取った公開鍵証明書で署名を検証します。
この証明書は個別配布のほか、SAMLメタデータに埋め込んで配布することも可能です。

5. ブラウザ経由でSPにアサーション送信

IdPはSAMLアサーションをブラウザに返し、ブラウザはHTTP POSTでSPのAssertion Consumer Service(ACS)に送信します(HTTP-POSTバインディング)。
ブラウザは内容を解析せず、そのまま中継します。

6. SPがアサーションを検証

SPは受け取ったアサーションについて、

  1. 署名検証(公開鍵で改ざんの有無を確認)
  2. 発行元確認(想定しているIdPかどうか)
  3. 有効期限確認(NotBefore / NotOnOrAfterのチェック)
  4. 宛先確認(自分宛かどうか)
    を行います。

7. ログイン完了

検証に問題がなければ、SPはユーザーを認証済みとしてセッションを発行し、サービス利用を許可します。

4. 公開鍵証明書とメタデータ

  • 公開鍵証明書:公開鍵と、その正当性を保証する情報を含む。SPはこれを使ってアサーションの署名を検証。
  • SAMLメタデータXML:証明書(X.509形式)やエンドポイントURLなどを含み、SPやIdPの設定を自動化できる。
  • メタデータはHTTPSなどの安全な経路で配布する必要があります。

5. 鍵の管理とローテーション

  • IdPの秘密鍵は長期間使い続けず、定期的に交換(キーローテーション)するのが推奨。
  • 証明書の有効期限(一般的に1〜3年)に合わせて更新することが多い。
  • 交換時は新しい証明書をSPに配布し、メタデータも更新。
  • 切り替え期間中は新旧両方の証明書を登録しておくと移行がスムーズ。

6. セキュリティ上の注意点

  • SAMLアサーションは短時間のみ有効(数分)に設定し、リプレイ攻撃を防ぐ。
  • 通信路は必ずTLS(HTTPS)で暗号化。署名は改ざん防止であり、通信の秘匿にはならない。
  • メタデータ更新や証明書更新の作業は、IdPとSPの双方でタイミングを合わせる必要がある。

まとめ

SAML認証は、IdPがユーザーを認証し、その結果や属性情報をSAMLアサーションとしてSPに安全に渡すことでSSOを実現します。
アサーションは秘密鍵で署名され、SPは公開鍵証明書やメタデータを使って検証します。
この仕組みにより、異なるサービス間でも安全かつ効率的にログイン状態を共有でき、アクセス制御にも活用できるのがSAMLの強みです。

1
0
0

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
1
0

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?