SAML 2.0-Based Single Sign-On (SSO) and Identity Federation

1. Overview

A. Definition and Background

SAML (Security Assertion Markup Language) is an OASIS standard for securely exchanging authentication, authorization, and attribute information as standardized XML-based Assertions across different security domains. SAML 2.0 in particular has become the de facto enterprise standard for Single Sign-On (SSO) and Identity Federation mediated by the web browser. In short, SAML is a trust-relay protocol in which an Identity Provider (IdP) declares "who the user is (authentication) and what they may do (authorization/attributes)," and a Service Provider (SP) trusts that declaration in lieu of its own login.

SAML emerged from the recognition that "a model requiring a separate login per application does not scale." As the SaaS and internal systems an organization uses grow to tens or hundreds, each application ends up storing its own user accounts and passwords. This produces repeated logins and password fatigue for users, a account-lifecycle (provisioning/deprovisioning) burden of creating and deleting accounts system-by-system for administrators, and a security problem in which passwords scattered across many places cause the attack surface to grow linearly. SAML structurally resolves this by concentrating the responsibility for authentication into a single point of trust (the IdP) and letting every other application simply consume the result.

Historically, SAML 1.0/1.1 appeared in 2002–2003, and SAML 2.0, still in use today, was standardized by OASIS in 2005. Version 2.0 converged elements of the then-competing Liberty Alliance ID-FF and Shibboleth into one, which is why SAML 2.0 is not backward compatible with earlier versions. Nearly two decades later, it remains central to academic federations (eduGAIN/InCommon), government and financial B2B portals, and enterprise SSO integrations of large SaaS products (e.g., Microsoft 365, Salesforce, Google Workspace). While the mobile/API/native-app era brought the lightweight JSON-based [[oauth2-oidc]] to prominence, SAML still holds an irreplaceable position in browser-based enterprise web SSO.

B. Necessity

The necessity of SAML can be explained from the user, administrator, and security perspectives. For users, a single authentication grants access to all federated services without re-login, raising productivity. For administrators, accounts and permissions are controlled centrally in one place (the IdP), so when an employee leaves, disabling a single IdP account immediately blocks access to all integrated SPs. This is a powerful control that eliminates incidents caused by "ghost accounts" at the source.

The security perspective is especially important. In a SAML integration, the user's password is never transmitted to the SP (service). The user presents credentials only to the IdP, and the SP receives only an IdP-signed Assertion. This eliminates the risk of passwords being stored across dozens of SaaS products, and strengthening policies such as multi-factor authentication (MFA) or risk-based authentication need only be applied at the single IdP to be enforced consistently enterprise-wide. In Korea as well, such central authentication control forms the basis for satisfying compliance (the access-control requirements of ISMS-P) in e-government service linkage and the integrated group portals of the financial sector.

C. Core Characteristics

SAML's characteristics condense into three points. First is XML-based Assertions and digital signatures: every message is an XML document, protected against tampering by XML Signature (XML-DSig) and, where needed, given confidentiality by XML Encryption. Second is a browser-redirect-centric front-channel protocol: domain-crossing trust is relayed using only standard web-browser redirects/form POSTs, with no separate client. Third is metadata-based pre-established trust: the IdP and SP exchange XML metadata containing each other's endpoints and certificates in advance to build a static trust relationship. These three characteristics combine to make SAML a mature, conservative enterprise protocol that "fixes trust through configuration and guarantees integrity through signatures."

2. Overall Structure and Components of SAML

SAML is not a single message specification but a layered framework along four axes: Assertion (what is being stated), Protocol (how it is exchanged), Binding (which transport layer it rides on), and Profile (a combination for a specific use scenario). Below is an overall structure diagram showing the trust relationships among the main actors and components.

flowchart LR
  subgraph USER["User domain"]
    UA["Web browser (User Agent)"]
  end
  subgraph IDPDOM["IdP security domain"]
    IDP["Identity Provider (IdP)"]
    DIR["User directory (LDAP/AD)"]
    IDP --- DIR
  end
  subgraph SPDOM["SP security domain"]
    SP["Service Provider (SP)"]
    APP["Protected resource (application)"]
    SP --- APP
  end
  UA -->|"① Access / auth request"| SP
  SP -->|"② AuthnRequest (signed)"| UA
  UA -->|"③ Present credentials"| IDP
  IDP -->|"④ Signed Assertion"| UA
  UA -->|"⑤ Relay Assertion"| SP
  IDP <-.->|"Metadata/cert pre-exchange (trust setup)"| SP

The key to this structure is that the IdP and SP do not communicate directly with the user in between; instead they use the browser as a 'trust relayer.' The two sides fix trust in advance by exchanging metadata (endpoint URLs, X.509 public-key certificates, supported bindings), and at the actual moment of login the browser carries the signed messages to each side. In this way, cross-domain SSO holds even when the IdP and SP are not directly connected by a network path.

A. Core Actors — IdP, SP, Principal

SAML's three protagonists are the Principal (usually the end user), the Identity Provider (IdP), and the Service Provider (SP). The IdP is coupled with the organization's user directory (Active Directory/LDAP) and is the "source of trust" that actually authenticates users and issues Assertions. The SP holds protected resources but does not authenticate on its own; it is the "consumer of trust" that consumes the IdP's Assertions.

This separation of roles defines SAML's security model. Because the SP stores no passwords, user credentials are not leaked even if the SP is breached, and authentication hardening (applying MFA, restricting access locations) can be concentrated at the IdP alone. Conversely, this means the IdP becomes the enterprise-wide Single Point of Trust and Single Point of Failure (SPOF). If the IdP goes down, new logins to all integrated SPs become impossible, so the IdP's high availability and redundancy become the top non-functional requirement of a SAML architecture. In practice, large organizations multiplex the IdP active-active and deploy it across regions to secure availability.

B. The Three Kinds of Assertion — Authentication, Attribute, Authorization Decision

A SAML Assertion is a "statement" the IdP declares about the Principal, and it contains one of three kinds of Statement depending on its content. Their meanings and practical uses are as follows.

Category	Statement type	Information carried	Practical example
Authentication	AuthnStatement	Authentication time/method (AuthnContext)	"This user authenticated at 10:05 with MFA"
Attribute	AttributeStatement	User attributes such as email, department, role	Grant permissions within the SP using the department attribute
Authorization decision	AuthzDecisionStatement	Allow/deny access to a specific resource	(Rarely used today; replaced by XACML)

The most important in practice are the AuthnStatement and AttributeStatement. The AuthnStatement's AuthnContext expresses "with what strength the user authenticated," letting the SP implement step-up authentication such as "this resource allows only sessions authenticated with MFA." The AttributeStatement conveys attributes such as the user's department, title, or group, enabling the SP to perform role-based access control (RBAC) using only the attributes carried in the Assertion, without a separate user database. For example, the accounting module is exposed only to users with the "Finance team" attribute. Thus attribute delivery is the point where simple login extends into "attribute-based authorization."

C. Binding and Profile — Transport and Scenarios

Binding defines which transport mechanism carries a SAML message. The representative ones are the HTTP-Redirect binding (the message is compressed and encoded into the URL query, suitable for short AuthnRequests), the HTTP-POST binding (the message is auto-submitted as a hidden field in an HTML form, suitable for conveying large signed Assertions), and the Artifact binding (only a short reference value (artifact) is passed to the browser while the actual Assertion is exchanged directly over a back channel between IdP and SP). The Artifact binding has lower exposure risk because the Assertion does not pass through the browser, but it has the constraint of requiring a direct communication path between the SP and IdP.

A Profile is a "usage guideline" that combines these elements for a specific scenario. The most widely used is the Web Browser SSO Profile, which most enterprise SAML integrations follow. Others include the Single Logout (SLO) Profile, which terminates all SP sessions with a single IdP logout, and the Metadata Profile, which standardizes metadata exchange. Thus SAML covers diverse situations through combinations of the four axes, but in practice "Web Browser SSO + HTTP-POST binding + signed Assertion" is effectively the standard combination.

D. Metadata and Pre-Established Trust

The decisive way SAML differs from OIDC's Dynamic Client Registration is that it fixes the trust relationship statically in advance through metadata exchange, not at runtime. The IdP and SP each publish a standard XML metadata document containing their own EntityID, endpoint URLs (SSO/ACS/SLO), X.509 public-key certificates for signing/encryption, and list of supported bindings, and the integration partner fetches and registers this in its own configuration. The moment this exchange is complete, a trust path is established between the two domains in which each can "verify the other's signature with its public key and know which URL to send messages to."

This static trust model has clear pros and cons. The advantage is that there is no need to negotiate trust with an unknown party at runtime, so the attack surface is small and predictable. The disadvantage is that when a certificate expires or is rotated, the integration breaks entirely unless both sides' metadata are updated together, and in fact a large share of SAML outages originate from "IdP signing-certificate expiry." Accordingly, large federations (InCommon, eduGAIN, etc.) operate a metadata aggregate and automatic refresh system that gathers and periodically distributes the metadata of many institutions, and even individual integrations make certificate-expiry monitoring and rollover procedures an operational standard.

3. SP-Initiated SSO Flow

SAML SSO divides, by who initiates the flow, into SP-Initiated (the user accesses the SP first) and IdP-Initiated (the user clicks an app in the IdP portal). The SP-Initiated flow, which is the enterprise standard and recommended for security, is shown in detail below.

sequenceDiagram
  participant U as Browser
  participant S as SP (service)
  participant I as IdP (auth server)
  U->>S: ① Request protected resource (unauthenticated)
  S->>U: ② Generate AuthnRequest, redirect
  U->>I: ③ Relay AuthnRequest
  I->>U: ④ Login form (if unauthenticated)
  U->>I: ⑤ Present credentials + MFA
  I->>I: ⑥ Verify user, create Assertion, sign
  I->>U: ⑦ HTML Form (POST) + signed Assertion
  U->>S: ⑧ POST Assertion to ACS
  S->>S: ⑨ Verify signature, conditions, Audience
  S->>U: ⑩ Establish session, serve resource

The flow begins at steps ①–②. When an unauthenticated user requests the SP's protected resource, the SP creates an AuthnRequest (authentication-request XML) and redirects the user to the IdP. Here the SP signs the request to prove it is a legitimate SP, and it also sends an identifier (ID) to match the later response with the request and a RelayState carrying the original destination. RelayState is the "deep-link restoration" device that returns the user to the page they originally requested after login.

Steps ③–⑦ are the IdP's authentication segment. If the user already has a logged-in session, the IdP issues the Assertion immediately without re-authentication (this is the heart of SSO — from the second SP onward, no login screen appears at all); otherwise it presents a login form and verifies credentials and MFA. Once verification is complete, the IdP creates an Assertion carrying the user identifier (NameID), attributes, and authentication context, signs it with XML-DSig, and returns it to the browser as an auto-submitting HTML form according to the HTTP-POST binding.

Steps ⑧–⑩ are the SP's verification segment and the heart of security. The browser POSTs the Assertion to the SP's ACS (Assertion Consumer Service) endpoint, and the SP strictly verifies the received Assertion. Specifically, it ⓐ verifies the signature with the IdP's public key to confirm the absence of tampering and the authenticity of the sender, ⓑ checks the validity time with NotBefore/NotOnOrAfter to prevent expiry/reuse, ⓒ confirms with the Audience restriction whether the Assertion was issued precisely for itself (the SP), and ⓓ checks whether the ID of the previously sent AuthnRequest matches the response's InResponseTo. Only when all four of these verifications pass does the SP establish a local session and serve the resource. If this verification step is lax, it is exposed to the various attacks described later, so the success or failure of SAML security effectively hinges on "the strictness of the SP's Assertion verification."

By contrast, IdP-Initiated SSO is a flow in which, when the user clicks a particular app in the IdP portal (e.g., an internal app dashboard), the IdP immediately generates an Assertion without an AuthnRequest and sends it to the SP's ACS. The user experience is intuitive, but because the SP has no InResponseTo with which to check whether it is "a response to a request it sent," request-response correlation verification is impossible, and as a result it is relatively vulnerable to login-CSRF-type attacks in which an attacker funnels a stolen or forged Assertion into a victim's browser. For this reason OWASP and many security guides recommend adopting the SP-Initiated flow by default where possible and, where IdP-Initiated is unavoidable, enforcing one-time-use Assertion management and short validity times. This shows that the choice of flow is itself a security-design decision.

4. SAML vs. OIDC and Kerberos

To properly position SAML, one must understand its differences from similar technologies down to "why those differences arise." The comparison below is not a mere enumeration but carries the practical implications stemming from differences in design purpose.

Item	SAML 2.0	OAuth 2.0 / OIDC	Kerberos
Standardization	OASIS (2005)	IETF (OAuth 2012, OIDC 2014)	MIT, IETF (RFC 4120)
Data format	XML / XML-DSig	JSON / JWT	Binary tickets
Primary use	Enterprise web SSO	Delegated authorization, API, mobile auth	Internal network (domain) auth
Transport	Browser redirect (front channel)	Redirect + back-channel tokens	TGT/TGS ticket exchange
Suitable environment	B2B, browser-centric SaaS	Native apps, SPA, microservices	Closed network, same domain

The difference between SAML and [[oauth2-oidc]] stems from "the era in which each was born and the client it targeted." SAML was designed on top of XML/SOAP culture in 2005, when web browsers dominated, aiming at B2B web SSO. OIDC, by contrast, was designed for an environment dominated by mobile apps, SPAs (Single Page Applications), and REST APIs in the 2010s, with a lightweight, mobile-friendly structure based on JSON/JWT. As a result, SAML's heavy XML parsing and signature processing is a burden that makes it unsuitable for native apps, but thanks to its mature metadata and signature system it remains the more conservative, battle-tested choice for enterprise web SSO. The core distinction is that OAuth is originally an "authorization (what you may do)" protocol, whereas SAML is a comprehensive protocol that includes "authentication (who you are)"; OIDC is OAuth with an authentication layer on top.

The difference from [[kerberos]] is decided at "the network boundary." Kerberos is optimized for fast ticket-based authentication within the same domain or a closed network, so it is strong for Windows-domain logins within an organization's LAN, but unsuitable for cross-domain or internet environments crossing firewalls. SAML, conversely, is strong at internet-crossing federation that links different organizations/domains via browser redirects. In real enterprises, a hybrid configuration is common in which intranet Kerberos login is combined with a SAML IdP, so that a user who has logged into Windows once inside the company can access external SaaS without re-authentication.

5. (Deep Dive) Major Security Threats and Recent Trends

SAML is a mature standard, but fatal vulnerabilities stemming from implementation flaws have been reported repeatedly. First, the XML Signature Wrapping (XSW) attack is a technique that, while keeping the signed original Assertion, inserts an attacker-crafted Assertion at a different location in the XML tree so that the signature verifier and the Assertion processor look at "different nodes." This causes a serious authentication bypass in which the signature is judged valid but the Assertion actually processed is forged. The defense is to enforce that the signature-verification target and the processing target are necessarily the same node, and to strictly perform schema validation and ID referencing.

Second is missing or lax signature verification. In 2018, a vulnerability was reported in many SAML libraries that abused differences in XML comment handling to manipulate the NameID (e.g., inserting a comment like user@victim.com<!----> to impersonate a different user). The root cause was an inconsistency in signature-scope and canonicalization handling. Third is the Replay attack, in which a stolen Assertion is retransmitted within its validity time; this must be blocked by strictly applying NotOnOrAfter and by one-time-use cache management of Assertion IDs. Fourth is missing Audience verification: if the SP does not check the Audience restriction, an Assertion intended for a different SP can be reused. The common lesson of these threats is that "SAML security depends not on the standard itself but on the strictness of the SP's verification implementation."

As a concrete case, around 2020 signature-verification and comment-handling flaws were disclosed as CVEs in many commercial SSO products and open-source libraries, leading to large-scale patching; this left the lesson that "even a battle-tested standard leads to a full authentication bypass if the implementation is wrong." Therefore, when newly building a SAML integration, it is advisable to verify library versions and CVE history and to include XSW and signature-bypass scenarios in penetration-test items.

As recent trends, while new integrations clearly shift to OIDC with the spread of mobile/API, the vast base of existing enterprise SAML assets has made identity brokers (Keycloak, Okta, Microsoft Entra ID, etc.) that perform SAML↔OIDC token exchange (brokered federation) commonplace. Also, in a zero-trust ([[zero-trust]]) architecture, the SAML IdP is combined with the enforcement/decision points (PEP/PDP) of continuous authentication and Conditional Access policies, evolving beyond a simple one-time login toward requiring re-authentication in response to risk signals during a session. Pairing SAML (authentication) with SCIM (account provisioning) for user-lifecycle automation is also current standard practice.

6. Considerations and Implications

Considerations when designing and operating a SAML deployment from a professional-engineer perspective are as follows.

• Adoption strategy (technology-selection criteria): A "use-based separation" is reasonable — applying OIDC to new mobile/API/SPA-centric services and SAML to existing B2B browser-based SaaS and academic/government federations. However, when the two heterogeneous systems coexist, management complexity grows, so in the mid-to-long term one should aim at an architecture that places an identity broker to mediate and converge the two protocols.

• Trade-off (availability vs. security concentration): Concentrating authentication at the IdP maximizes security control and MFA consistency, but makes the IdP an enterprise-wide SPOF. Therefore active-active redundancy of the IdP, regional distribution, and session-persistence design are essential, and a break-glass account operating procedure for IdP failure must be prepared in advance. The key is to design for both the benefit of concentration and the risk of concentration simultaneously.

• Implementation security (enforcing verification strictness): Most SAML incidents originate not from the standard but from SP-side Assertion-verification flaws. The identity of the signature-verification target and the processing target (XSW defense), mandatory verification of Audience/NotOnOrAfter/InResponseTo, one-time-use Assertion management, use of verified libraries, and regular patching must be pinned down as organizational standards. Avoid custom XML-parsing implementations and reuse mature implementations.

• Operations/governance (lifecycle and logout): SSO brings both the convenience of "one login" and the risk that "if one is stolen, all apps are open." Therefore session-lifetime and re-authentication-cycle policies should be unified organization-wide, and SAML should be linked with SCIM provisioning so that resignations and permission changes are reflected immediately across all SPs. Also, Single Logout (SLO) is tricky to implement in practice due to binding and session-state mismatches, carrying a "residual session" risk where logout is not propagated to some SPs; include SLO support in the integration-review checklist and shorten session timeouts for SPs that do not support it.

• Outlook and related technologies: SAML's new adoption has stalled, but owing to the scale of existing assets it will persist in enterprise fields for more than a decade. Therefore, rather than "removing SAML," a realistic strategy is "raising operational quality by integrating SAML with zero-trust, Conditional Access, and SCIM provisioning." Collecting central logs into a [[siem]] to detect authentication anomalies and shortening re-authentication cycles/token lifetimes against session hijacking should proceed in parallel.

References

• OASIS, "Security Assertion Markup Language (SAML) V2.0 Technical Overview": https://docs.oasis-open.org/security/saml/Post2.0/sstc-saml-tech-overview-2.0.html
• OASIS SAML 2.0 Specifications (Core/Bindings/Profiles): https://wiki.oasis-open.org/security/FrontPage
• Duo Labs, "Duo Finds SAML Vulnerabilities Affecting Multiple Implementations": https://duo.com/blog/duo-finds-saml-vulnerabilities-affecting-multiple-implementations
• OWASP, "SAML Security Cheat Sheet": https://cheatsheetseries.owasp.org/cheatsheets/SAML_Security_Cheat_Sheet.html

---

In one line: SAML 2.0 is a mature enterprise authentication standard that realizes cross-domain web SSO and federation by having the browser relay an IdP-signed XML Assertion to the SP; its security hinges on the strictness of the SP's Assertion verification, and integrated operation with OIDC, zero trust, and SCIM is the key task going forward.