セキュリティ

SAMLリクエストとは：AuthnRequestの要素・デコード・署名とエラー対処

SAMLリクエストとは：AuthnRequestの要素・デコード・署名とエラー対処

SAMLリクエストは、SPがIdPに「この利用者を認証して結果を返してほしい」と頼むXMLメッセージで、SSOのログインではAuthnRequest要素として送られます。この記事では、AuthnRequestの属性と子要素をOASIS SAML 2.0のCore仕様で読み、SAMLRequestのデコードとRedirectでの署名・検証をPythonで実行する内容です。StatusCodeとEntra IDのAADSTSエラーから原因の要素を突き止める手順、自社のSPで送る要素の判断までをまとめます。

まとめ：SAMLリクエストの必須要素と署名とエラー切り分けの順序

AuthnRequestで必須なのはID、Version、IssueInstantの3属性だけです。ただしWeb Browser SSOではIssuerも必須になり、IdPに登録したSPのentityIDと1文字違わず一致させる必要があります。IDは数字で始められません。

応答の届け先は、ACSのURLとProtocolBindingの組か、メタデータ上のindexかのどちらか一方で指定します。両方を書くと仕様違反です。

エラーが出たら、まずSAMLRequestを復号して中身を見ます。Issuer、ACS URL、NameIDPolicy、RequestedAuthnContextの4か所が、大半の原因を見つけるための確認対象です。自社のSPでは、要求に署名を付け、RequestedAuthnContextとSubjectは要件が無い限り送らない構成を勧めます。

SAMLリクエストの役割とAuthnRequestがSSOで送られる場面

SAMLの全体像やIdPとSPの関係はSAMLとは？認証フロー・IdP/SPの仕組みとOAuth・OIDCとの使い分けを実装視点で解説で扱っています。ここでは要求メッセージだけに絞ります。

SPが作りIdPが読むAuthnRequestと応答のInResponseTo

SAMLの要求メッセージはどれもOASIS SAML 2.0 Core仕様のSection 3.2.1が定めるRequestAbstractTypeを土台にし、ログインで使うのがSection 3.4.1のAuthnRequestです。

利用者がSPの保護ページを開くと、SPはAuthnRequestを作ってブラウザ経由でIdPへ送ります。IdPは認証を済ませてResponseを返し、そのInResponseTo属性に入る値は、SPが送った要求のIDです。Section 3.2.1は要求のIDと応答のInResponseToが一致しなければならないと定めており、SPはこの照合で「自分が出した要求への答えか」を確かめます。

要求なしに応答だけが届く方式はSAML IdP-initiatedとは：SP-initiatedとの違いとACS実装の判断で扱っています。

SAMLRequestパラメータで届くRedirectとPOSTの2つの運び方

AuthnRequestはXMLのままでは送られません。HTTP-Redirectでは、XMLにraw DEFLATEとbase64とURLエンコードを掛け、SAMLRequestというクエリパラメータに載せます。HTTP-POSTでは、base64だけを掛けた値を同じ名前のフォーム項目に入れます。

Entra IDは要求をRedirectで受け取ります。開発者ツールでIdPへのGETを探し、URLのSAMLRequest=の値を復号します。2つの方式の符号化と署名の違いはSAML HTTP POSTバインディングとは：Redirect・Artifactとの違いにまとめました。

AuthnRequestの属性と子要素をCore仕様3.4.1の定義で読む

次のXMLは、業務システムのSPが送る典型的なAuthnRequestです。以降の節で、属性と子要素を上から順に読みます。

<samlp:AuthnRequest xmlns:samlp="urn:oasis:names:tc:SAML:2.0:protocol"
    xmlns:saml="urn:oasis:names:tc:SAML:2.0:assertion"
    ID="_36686b28e26b3d1f0c9e4a7b5d2f8a1c6e0b9d34"
    Version="2.0"
    IssueInstant="2026-11-05T01:00:00Z"
    Destination="https://idp.example.jp/sso"
    AssertionConsumerServiceURL="https://sp.example.jp/saml/acs"
    ProtocolBinding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST">
  <saml:Issuer>https://sp.example.jp/metadata</saml:Issuer>
  <samlp:NameIDPolicy Format="urn:oasis:names:tc:SAML:2.0:nameid-format:persistent"
      AllowCreate="true"/>
</samlp:AuthnRequest>

子要素の並び順はスキーマで固定されており、Issuer、Signature、Extensions、Subject、NameIDPolicy、Conditions、RequestedAuthnContext、Scopingの順です。順序を入れ替えると、スキーマ検証をするIdPでは要求全体が不正と判定されます。

ID・Version・IssueInstantの必須3属性とIDを数字で始めない規則

必須属性はこの3つです。IDの型はxs:IDで、W3C XML Schema Part 2の定義上、XMLの名前規則に従うため先頭に数字を置けません。GUIDの16進表記は62.5%の確率で数字始まりになるため、Microsoft LearnのSingle sign-on SAML protocolもidなどの前置を勧めています。

Core仕様のSection 1.3.4は、乱数でIDを作る場合に衝突確率を2のマイナス128乗以下、望ましくは2のマイナス160乗以下にするよう求めています。128から160ビットの乱数を符号化すれば満たせます。

Versionは2.0固定、IssueInstantはUTCの日時です。Entra IDは値を評価しませんが、受信時刻とのずれで拒否するIdPもあるため、SPの時刻はNTPで同期します。

IssuerとDestinationでIdPが要求元と宛先を確かめる仕組み

Core仕様ではIssuerは任意ですが、OASIS SAML 2.0 Profiles仕様のSection 4.1.4.1は、Web Browser SSOではIssuerを必須とし、要求元SPの一意な識別子を入れるよう定めています。Format属性は省略するか、entity形式にします。

IdPはIssuerで登録済みのSPを引き当てます。Entra IDではIssuerがアプリの識別子（ServicePrincipalNames）のいずれかと完全一致しなければならず、末尾のスラッシュ1つの差でもアプリが見つからないエラーになります。

Destinationは要求を送った先のURLです。値があれば、受け手は実際の受信URLと照合し、一致しなければ要求を破棄する決まりです（Section 3.2.1）。Entra IDは無視しますが、照合するIdPに備えてメタデータのSingleSignOnServiceと同じ値を入れます。

ACS URLとProtocolBindingかIndexかを選ぶ排他の指定

応答の届け先は2通りで指定できます。AssertionConsumerServiceURLにURLを直接書きProtocolBindingを添える方法と、AssertionConsumerServiceIndexでメタデータに登録したACSの番号を指す方法です。Section 3.4.1は両者を排他と定めています。

指定方法 書く属性 省略時 向く構成
URLで指定 ACS URLとProtocolBinding 既定のACSに返る ACSが1本のSP
番号で指定 ACSのインデックス属性 既定のACSに返る ACSを複数持つSP
何も書かない なし isDefaultのACSに返る IdP側の登録だけで運用

表の「ACSのインデックス属性」はAssertionConsumerServiceIndex、「ACS URL」はAssertionConsumerServiceURLの略記です。

Profiles仕様のSection 4.1.4.1は、署名の有無にかかわらず、IdPがACSのURLや番号を要求元SPの登録値と照合するよう求めています。リバースプロキシの裏でSPが自分のURLをhttpで組み立てると、登録済みのhttpsと食い違って拒否されます。ACSの登録方法はSAMLメタデータとは：EntityDescriptorの読み方と署名証明書の更新手順を参照してください。

NameIDPolicyのFormatとAllowCreateで変わる返却されるID

NameIDPolicyは、応答に入る利用者識別子の形式を指定する子要素です。Formatを省略するかunspecifiedにすると、IdPが形式を選びます。Section 3.4.1.1によると、IdPが指定を受け付けられない場合はエラーを返し、第2階層のStatusCodeにInvalidNameIDPolicyを入れてよいとされています。

AllowCreateの既定値はfalseです。falseのままだと、IdPがそのSP向けの識別子をまだ作っていない利用者は認証に失敗します。persistent形式で初回ログインを通すにはtrueを指定してください。

Entra IDが受け付けるFormatは、persistent、emailAddress、unspecified、transientの4つだけで、それ以外は即エラーになります。AllowCreateはEntra IDでは無視される属性です。Formatの選び方と、指定しても別の形式が返る場合の対処はSAML NameIDFormatとメタデータの不一致でSSOが失敗する原因の切り分けで扱っています。

再認証・無操作認証・認証方式の要求で使う属性と子要素の指定条件

ForceAuthnをtrueにすると、IdPは既存のセッションに頼らず利用者を認証し直します。送金や権限変更の直前に本人確認をやり直させたい画面で使う属性です。IsPassiveをtrueにすると、IdPは画面を出さずに処理し、セッションが無ければNoPassiveのStatusCodeを返します。両方trueのときは、IsPassiveの制約が優先されます。

RequestedAuthnContextは、求める認証方式をURIで指定する子要素です。Section 3.3.2.2.1によると、Comparisonはexact、minimum、maximum、betterの4種類で既定はexact。満たせなければIdPはNoAuthnContextを返します。Entra IDはexactしか受け付けず、受理する12種類のクラスにPasswordProtectedTransportは含まれません。

SAMLリクエストを生成・署名・デコードして検証するPython実装

ここからは手元で動かします。外部パッケージは署名用のpycryptodomeだけです。

標準ライブラリとpycryptodomeで要求を生成・署名・診断するコード

次のスクリプトは、AuthnRequestを組み立ててRedirect用に符号化し、RSA-SHA256の署名を付けたURLを作ります。続けて、受け手の立場で署名を検証し、SAMLRequestを復号して要素の不備を診断します。

import base64
import secrets
import urllib.parse
import xml.etree.ElementTree as ET
import zlib
from datetime import datetime, timedelta, timezone

from Crypto.Hash import SHA256
from Crypto.PublicKey import RSA
from Crypto.Signature import pkcs1_15

NS = {
    "samlp": "urn:oasis:names:tc:SAML:2.0:protocol",
    "saml": "urn:oasis:names:tc:SAML:2.0:assertion",
}
RSA_SHA256 = "http://www.w3.org/2001/04/xmldsig-more#rsa-sha256"

SP_ENTITY_ID = "https://sp.example.jp/metadata"
SP_ACS_URLS = ["https://sp.example.jp/saml/acs"]
IDP_SSO_URL = "https://idp.example.jp/sso"


def build_authn_request(acs_url, request_id=None, force_authn=False):
    # ID は xs:ID なので数字で始めない。160ビットの乱数に "_" を前置する
    request_id = request_id or "_" + secrets.token_hex(20)
    issue_instant = datetime.now(timezone.utc).strftime("%Y-%m-%dT%H:%M:%SZ")
    force = ' ForceAuthn="true"' if force_authn else ""
    xml = (
        '<samlp:AuthnRequest xmlns:samlp="urn:oasis:names:tc:SAML:2.0:protocol" '
        'xmlns:saml="urn:oasis:names:tc:SAML:2.0:assertion" '
        f'ID="{request_id}" Version="2.0" IssueInstant="{issue_instant}" '
        f'Destination="{IDP_SSO_URL}" AssertionConsumerServiceURL="{acs_url}" '
        f'ProtocolBinding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST"{force}>'
        f"<saml:Issuer>{SP_ENTITY_ID}</saml:Issuer>"
        '<samlp:NameIDPolicy Format="urn:oasis:names:tc:SAML:2.0:nameid-format:persistent" '
        'AllowCreate="true"/>'
        "</samlp:AuthnRequest>"
    )
    return request_id, xml


def deflate_b64(xml):
    # HTTP-Redirect 用：zlib ヘッダなしの raw DEFLATE → base64
    c = zlib.compressobj(9, zlib.DEFLATED, -15)
    return base64.b64encode(c.compress(xml.encode("utf-8")) + c.flush()).decode("ascii")


def signed_redirect_url(xml, relay_state, key):
    # 署名対象は「SAMLRequest=..&RelayState=..&SigAlg=..」の URL エンコード済み文字列
    parts = [
        "SAMLRequest=" + urllib.parse.quote(deflate_b64(xml), safe=""),
        "RelayState=" + urllib.parse.quote(relay_state, safe=""),
        "SigAlg=" + urllib.parse.quote(RSA_SHA256, safe=""),
    ]
    signed = "&".join(parts)
    sig = pkcs1_15.new(key).sign(SHA256.new(signed.encode("ascii")))
    sig_q = "Signature=" + urllib.parse.quote(base64.b64encode(sig).decode("ascii"), safe="")
    return f"{IDP_SSO_URL}?{signed}&{sig_q}"


def verify_redirect_signature(url, public_key):
    # 受信側は「届いたままの」エンコード済み値を連結し直して検証する
    raw = dict(p.split("=", 1) for p in urllib.parse.urlsplit(url).query.split("&"))
    signed = "&".join(f"{k}={raw[k]}" for k in ("SAMLRequest", "RelayState", "SigAlg") if k in raw)
    sig = base64.b64decode(urllib.parse.unquote(raw["Signature"]))
    try:
        pkcs1_15.new(public_key).verify(SHA256.new(signed.encode("ascii")), sig)
        return True
    except ValueError:
        return False


def decode_saml_request(value, binding):
    data = base64.b64decode(value)
    if binding == "redirect":
        data = zlib.decompress(data, -15)
    return data.decode("utf-8")


def diagnose(xml, received_at=None, max_skew=timedelta(minutes=3)):
    # 学習用に標準ライブラリで読む。本番の受信処理では defusedxml 等で外部実体を無効にする
    root = ET.fromstring(xml)
    a = root.attrib
    issues = []
    if not a.get("ID") or a["ID"][0].isdigit():
        issues.append("ID が空か数字で始まっている（xs:ID 違反）")
    if a.get("Version") != "2.0":
        issues.append("Version が 2.0 ではない")
    issued = datetime.strptime(a["IssueInstant"], "%Y-%m-%dT%H:%M:%SZ").replace(tzinfo=timezone.utc)
    now = received_at or datetime.now(timezone.utc)
    if abs(now - issued) > max_skew:
        issues.append(f"IssueInstant と受信時刻の差が {int(abs(now - issued).total_seconds())} 秒")
    if a.get("Destination") not in (None, IDP_SSO_URL):
        issues.append("Destination が IdP の SSO URL と一致しない")
    issuer = root.findtext("saml:Issuer", namespaces=NS)
    if issuer != SP_ENTITY_ID:
        issues.append(f"Issuer {issuer!r} が登録済みの entityID と一致しない")
    if "AssertionConsumerServiceIndex" in a and "AssertionConsumerServiceURL" in a:
        issues.append("ACS の Index と URL を同時に指定している")
    acs = a.get("AssertionConsumerServiceURL")
    if acs and acs not in SP_ACS_URLS:
        issues.append(f"ACS URL {acs} がメタデータに登録されていない")
    if root.find("saml:Subject", NS) is not None:
        issues.append("Subject を含んでいる（Entra ID はエラーを返す）")
    return issues


if __name__ == "__main__":
    key = RSA.generate(2048)
    req_id, xml = build_authn_request(SP_ACS_URLS[0])
    url = signed_redirect_url(xml, "r-7Kq2", key)
    print("ID:", req_id[:12] + "...", "長さ", len(req_id))
    print("XML:", len(xml), "bytes / URL:", len(url), "chars")
    print("署名検証:", verify_redirect_signature(url, key.publickey()))
    tampered = url.replace("RelayState=r-7Kq2", "RelayState=r-XXXX")
    print("RelayState改ざん後の署名検証:", verify_redirect_signature(tampered, key.publickey()))

    q = urllib.parse.parse_qs(urllib.parse.urlsplit(url).query)
    decoded = decode_saml_request(q["SAMLRequest"][0], "redirect")
    print("復号一致:", decoded == xml, "/ 診断:", diagnose(decoded) or "問題なし")

    _, bad = build_authn_request("http://sp.example.jp/saml/acs", request_id="4f1c9a0b")
    late = datetime.now(timezone.utc) + timedelta(minutes=10)
    for msg in diagnose(bad, received_at=late):
        print("NG:", msg)

署名の対象は、OASIS SAML 2.0 Bindings仕様のSection 3.4.4.1に従い、URLエンコード済みのSAMLRequest、RelayState、SigAlgをこの順に&で連結した文字列です。受け手は届いたままのエンコード済みの値で連結し直して検証します。一度デコードしてから再エンコードすると、大文字小文字や記号の扱いの差で一致しなくなるためです。

Pythonの実行結果で見る改ざん検知とID・時刻・ACSの診断結果

Python 3.14.10とpycryptodome 4.3.0で実行した結果です。IDと署名は毎回変わるため、URLの長さは数文字ずれます。

ID: _36686b28e26... 長さ 41
XML: 566 bytes / URL: 971 chars
署名検証: True
RelayState改ざん後の署名検証: False
復号一致: True / 診断: 問題なし
NG: ID が空か数字で始まっている（xs:ID 違反）
NG: IssueInstant と受信時刻の差が 600 秒
NG: ACS URL http://sp.example.jp/saml/acs がメタデータに登録されていない

RelayStateを4文字書き換えただけで署名検証は失敗しました。Redirectの署名はクエリ全体を守るので、戻り先の差し替えも検知できます。

後半の3行は、数字始まりのID、10分遅れの要求、httpのACS URLを診断した結果です。ブラウザから採取した実データで同じ確認をすれば、IdPのエラー画面を待たずに原因を絞れます。

python3-samlの既定のAuthnRequestと変えるべき設定

実際のSPでは要求の生成をライブラリに任せます。python3-samlのソース（authn_request.pyとsettings.py）を読むと、既定のAuthnRequestには次の特徴があります。

  • IDはONELOGIN_にSHA-1の16進40文字を付けた値で、数字始まりにはならない
  • requestedAuthnContextの既定がtrueで、PasswordProtectedTransportをexactで要求する
  • authnRequestsSignedの既定がfalseで、署名は付かない
  • login()にname_id_value_reqを渡すと、SubjectConfirmation付きのSubjectが入る

問題になりやすいのは2つ目と4つ目です。PasswordProtectedTransportはEntra IDの受理一覧に無く、exactで比較される以上、利用者の認証方式と一致せず失敗する原因になりえます。Subjectについては、Profiles仕様のSection 4.1.4.1がSubjectConfirmationを含めてはならないと定め、Entra IDはSubjectそのものをエラーにします。

{
  "strict": true,
  "sp": {
    "entityId": "https://sp.example.jp/metadata",
    "assertionConsumerService": {
      "url": "https://sp.example.jp/saml/acs",
      "binding": "urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST"
    },
    "NameIDFormat": "urn:oasis:names:tc:SAML:2.0:nameid-format:persistent"
  },
  "security": {
    "authnRequestsSigned": true,
    "signatureAlgorithm": "http://www.w3.org/2001/04/xmldsig-more#rsa-sha256",
    "requestedAuthnContext": false
  }
}

requestedAuthnContextをfalseにすると要素自体が送られません。利用者を指定したい場合、Entra IDではSubjectではなくSSO URLのlogin_hintパラメータを使います。

IdPがSAMLリクエストを拒否したときのStatusCodeとエラー対処

要求に不備があると、IdPはエラー画面を出すか、エラーのStatusCodeを入れたResponseをACSへ返します。どちらの形で返るかはIdP次第です。

仕様のRequesterと第2階層StatusCodeから原因の要素を絞る

Core仕様のSection 3.2.2.2は、最上位のStatusCodeをSuccess、Requester、Responder、VersionMismatchの4つに限っています。要求の構文や処理規則に反するとき、IdPはRequesterを返さなければなりません（Section 3.2.1）。Requesterが返ったら、まずSP側の要求を疑います。

第2階層のStatusCode 疑う要素 SP側の対処
InvalidNameIDPolicy NameIDPolicyのFormat IdPが対応する形式に変える
NoAuthnContext RequestedAuthnContext 要素を外すかクラスを合わせる
NoPassive IsPassive falseで要求し直す
UnsupportedBinding ProtocolBinding HTTP-POSTを指定する
RequestUnsupported IdP未対応の属性や子要素 StatusMessageの要素名を外す
AuthnFailed 要求以外（認証の失敗） IdP側のログを確認する

第2階層のコードは、内部情報を探る攻撃を防ぐ目的で省いてよいとされています（Section 3.2.2.2）。無いときはStatusMessageとIdPのログを見ます。

Entra IDのAADSTSコードとAuthnRequestの原因箇所の対応表

Entra IDはStatusMessageやエラー画面にAADSTSで始まるコードを出します。Microsoft LearnのEntra認証エラーコード一覧のうち、AuthnRequestに原因があるものを要素と対応付けました。

コード 一覧の説明 見る要素
AADSTS700016 アプリがテナントに無い Issuerと送信先テナント
AADSTS50011 応答先が登録値と不一致 ACSのURL属性
AADSTS75011 認証方式が要求と不一致 RequestedAuthnContext
AADSTS76021 署名必須のアプリに未署名 SigAlgとSignature
AADSTS750054 RedirectでSAMLRequestが無い 送信方法とパラメータ名
AADSTS75005 SAML要求として不正 符号化とXMLの構文
AADSTS90015 クエリ文字列が長すぎる 要求の大きさとRedirect

AADSTS750054は、Redirectで受けるエンドポイントへSAMLRequestをフォームの本文で送った場合や、パラメータ名を誤った場合に出るコードです。AADSTS75005が出たら、前の章のコードで復号を試し、XMLとして読めるかを最初に確かめてください。

エラー画面のコードと実際に送られた要求を並べて見るには、ブラウザ拡張で通信を採取するのが早道です。採取から書き出しまでの手順はSAML-tracerの使い方：SSO失敗の原因を採取した通信から切り分けるにまとめました。

自社SPのSAMLリクエストで送る要素と送らない要素の判断基準

受託開発で業務システムにSAML SPを組み込むときの結論です。IdPがEntra ID、Okta、Keycloakのどれでも、方針は変わりません。

署名を付けるべき条件と最小構成で送るAuthnRequestの中身

送る要素は、必須3属性、Issuer、Destination、ACS URLとProtocolBinding、NameIDPolicyの7つで足ります。ACSが1本ならURLで指定し、複数のACSを持つマルチテナント構成ならindexで指定して、URLの組み立てミスをなくします。

署名は付けてください。Core仕様のSection 3.4.1はAuthnRequestに署名か通信路での保護を求めています。取引先のIdPを受け入れるSaaSなら、相手が署名必須に切り替えた日にログインが止まる事故も防げます。

テナント別のIdP設定や署名鍵の更新運用を含むSAML SPの組み込みは、一創の認証基盤・ID管理システム開発で設計から実装まで担当しています。

認証方式の要求やSubjectの指定が障害になる場面と送信を見送る条件

RequestedAuthnContextは、取引先のIdPが返す認証方式のURIを事前に確認できない限り送りません。パスキーやMFAへの移行でIdP側の方式が変わった時点で、SPの改修なしにログインが止まるからです。強い認証が必要なら、応答のAuthnStatementに入った方式を受信後に確かめる設計にします。応答側の読み方はSAMLアサーションとは：XML構造の読み方と署名・Audience・有効期限の検証実装で解説しています。

Subject、Conditions、Scopingも既定で送りません。ConditionsにはIdPが従う義務が無く、ScopingはIdPごとの対応差が大きいためです。ForceAuthnは再認証が要る画面に限って付けます。

よくある質問

SAMLリクエストについて、実装と障害対応でよく出る質問をまとめました。

SAMLリクエストとSAMLレスポンスの違いは何ですか？

SAMLリクエストはSPがIdPに認証を頼むメッセージで、ログインではAuthnRequest要素を使います。SAMLレスポンスはIdPが結果を返すメッセージで、成功時に含まれるのは署名付きのアサーションです。両者は要求のIDと応答のInResponseTo属性で対応付けられます。

SAMLRequestの中身はどうやってデコードしますか？

HTTP-Redirectで届いた値は、URLデコード、base64デコード、raw DEFLATEの展開の順で戻します。Pythonではzlib.decompress(data, -15)のように負のwbitsを渡すのが要点です。HTTP-POSTの値は圧縮されていないので、base64デコードだけでXMLになります。

AuthnRequestのIDはどう決めればよいですか？

128から160ビットの乱数を16進などで符号化し、先頭に_やidを付けます。型がxs:IDなので、数字で始まる値はスキーマ違反です。SPは送ったIDを保存し、応答のInResponseToと照合してください。

SAMLリクエストに署名は必要ですか？

仕様上は任意ですが、付けることを勧めます。署名が無い要求の中身は、IdPに参考情報としてしか扱われません。Redirectバインディングでは、XMLではなくSAMLRequest、RelayState、SigAlgを連結した文字列に署名し、SignatureとSigAlgのクエリパラメータで送ります。

AADSTS75011が出たときは何を直せばよいですか？

AuthnRequestのRequestedAuthnContextで求めた認証方式と、利用者が実際に使った方式が一致しないときのエラーです。python3-samlは既定でPasswordProtectedTransportを要求し、このクラスはEntra IDの受理一覧に無いため、両者を組むと起こりえます。設定のrequestedAuthnContextをfalseにし、MFAなどの要件は条件付きアクセスで課します。

関連記事

お気に入りに入れた記事の一覧

一創の公式 SNS

X では毎朝の新着記事と IT ニュースの速報を、YouTube・TikTok・Instagram・LinkedIn・Facebook では記事の解説動画を配信しています。

この記事は以下の記事からリンクされています

この記事に関連するサービス

資料請求

今日のトレンド記事 直近 24 時間で、いつもより多く読まれている記事

  1. 2026.11.03　テックブログ クラブツーリズム不正アクセス：約432万件の対象確認と偽メールの見分け方・流出検知の設計
  2. 2026.11.05　テックブログ Linuxカーネルの脆弱性CVE-2026-98432：修正版の見分け方とnftablesの緩和策
  3. 2026.10.29　テックブログ ソニー生命の情報漏洩38.5万件｜ログインできない理由、再開状況と窓口の電話番号
  4. 2026.11.04　テックブログ CVE-2026-119977：WordPress更新中のRCEと安全な更新手順
  5. 2026.10.31　テックブログ 松屋の不正アクセス：237万件の対象確認と窓口、漏れたパスワードの守り方

RELATED POSTS 関連記事

一覧へ戻る

目次