OASIS Standard: SAML 2.0 Core Enterprise Security Architect Grade

SAML 2.0 Master Study Notes & Enterprise Architecture Guide

Comprehensive engineering documentation covering XML assertions, bindings, canonicalization (C14N), digital signatures (XMLDSig), SubjectConfirmation, Single Logout (SLO), and Microsoft Entra ID enterprise app integration.

🏛️ 1. Core Concepts 📑 2. XML Anatomy 🚀 3. SAML Bindings 🔒 4. XMLDSig & C14N 👤 5. NameID Formats ☁️ 6. Entra ID Guide

Module 1

1. SAML 2.0 Architectural Foundations

Security Assertion Markup Language (SAML) 2.0 OASIS standard overview and trust model.

👤

Principal (End User)

The human user agent operating a web browser. The user authenticates against the Identity Provider without revealing raw corporate credentials (passwords, MFA secrets) to the Service Provider.

🏢

Service Provider (SP)

The business application relying on SAML assertions (e.g., saml.ntmscloud.in, Salesforce, ServiceNow). The SP verifies incoming cryptographic assertions and establishes local application sessions.

☁️

Identity Provider (IdP)

The centralized authentication authority (Microsoft Entra ID, Okta, PingFederate). The IdP maintains user directories, evaluates Conditional Access and MFA, and signs SAML assertions using private X.509 keys.

🔑 How Trust is Established (The Metadata Exchange):

Before any user can sign in, the SP and IdP establish mutual trust out-of-band by exchanging SAML Metadata XML documents (<md:EntityDescriptor>). The SP registers its Entity ID and ACS URL in Entra ID, while downloading the IdP's public X.509 Signing Certificate (NTMS-APP-SAML.cer) to verify future signed assertions.

Module 2

2. Anatomy of SAML XML Documents

Detailed structural breakdown of AuthnRequest, SAMLResponse, and Assertion elements.

A. <samlp:AuthnRequest> (SP → IdP)

HTTP-Redirect

<samlp:AuthnRequest ID="_a1b2c3d4-..." Version="2.0" IssueInstant="2026-10-13T14:30:00Z" Destination="https://login.microsoftonline.com/9e61.../saml2" AssertionConsumerServiceURL="https://saml.ntmscloud.in/saml/acs" ProtocolBinding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST"> <saml:Issuer>https://saml.ntmscloud.in/saml/metadata</saml:Issuer> <samlp:NameIDPolicy Format="urn:...:nameid-format:unspecified" AllowCreate="true"/> </samlp:AuthnRequest>

ID: Unique random GUID prefixed with underscore; matched in InResponseTo to prevent replay.

Destination: Target IdP SSO URL where request must be sent.

AssertionConsumerServiceURL: SP endpoint where IdP must post the response.

ProtocolBinding: SP instructs IdP to return assertion via HTTP-POST.

B. <saml:Assertion> (IdP → SP)

HTTP-POST

<saml:Assertion ID="_assert_8921" IssueInstant="2026-10-13T14:30:15Z"> <saml:Issuer>https://sts.windows.net/9e615794-.../</saml:Issuer> <ds:Signature>...</ds:Signature> <saml:Subject> <saml:NameID>sanjay.dubey@outlook.com</saml:NameID> <saml:SubjectConfirmation Method="urn:...:cm:bearer"> <saml:SubjectConfirmationData Recipient="https://saml.ntmscloud.in/saml/acs" NotOnOrAfter="2026-10-13T15:30:15Z"/> </saml:SubjectConfirmation> </saml:Subject> <saml:Conditions NotBefore="2026-10-13T14:30:15Z" NotOnOrAfter="2026-10-13T15:30:15Z"> <saml:AudienceRestriction> <saml:Audience>https://saml.ntmscloud.in/saml/metadata</saml:Audience> </saml:AudienceRestriction> </saml:Conditions> <saml:AttributeStatement> <saml:Attribute Name="roles"><saml:AttributeValue>EnterpriseApp.Admin</saml:AttributeValue></saml:Attribute> </saml:AttributeStatement> </saml:Assertion>

Subject Confirmation: Bearer confirmation permits party holding the assertion to authenticate at the Recipient ACS.

Conditions: Temporal validity window (NotBefore / NotOnOrAfter) and audience whitelist.

AttributeStatement: Multi-valued claims (roles, department, groups, email).

Module 3

3. SAML 2.0 Protocol Bindings Explained

How SAML protocol messages are packaged and transported over standard HTTP.

1. HTTP-Redirect

GET with Query Parameters

Message is deflated with RFC 1951 Deflate compression, Base64-encoded, and URL-encoded as query parameter ?SAMLRequest=....

Pipeline: XML → Deflate → Base64 → URLEncode

⚠️ Best for AuthnRequest. Limited to ~2KB URL limits in older browsers/proxies.

2. HTTP-POST

Form POST with Body Payload

Message is directly Base64-encoded (NO Deflate!) and placed inside a hidden HTML input field <input type="hidden" name="SAMLResponse">.

Pipeline: XML → Base64 → Form POST Body

✅ Standard for SAMLResponse. Can handle multi-kilobyte signed XML assertions with groups.

3. HTTP-Artifact

2-Step Back-Channel Resolution

The IdP passes only a small opaque token (SAMLart) via the browser. The SP contacts the IdP directly via back-channel SOAP to exchange the artifact for the actual assertion.

Pipeline: SAMLart → SOAP ArtifactResolve → Assertion

🛡️ Highest privacy: Browser never observes the raw assertion. Requires direct SP-to-IdP network route.

Module 4

4. XML Digital Signatures (XMLDSig) & Canonicalization (C14N)

Understanding why XML signatures differ fundamentally from JSON Web Signatures (JWS).

Why XML Needs Canonicalization (C14N)

In XML, two documents can be semantically identical while having completely different byte streams (differing whitespace, newline conventions, attribute ordering, namespace prefixes).

<tag a="1" b="2" /> (Differs in byte hashes!)

<tag b="2" a="1"></tag> (Canonicalized to same form)

Canonicalization Method (C14N): Converts XML into a standardized canonical byte representation prior to computing SHA-256 digests. Standard SAML uses http://www.w3.org/2001/10/xml-exc-c14n# (Exclusive Canonicalization).

Enveloped vs Response Signatures

In SAML, a signature can sign:

The Full <samlp:Response> element: Protects the outer status and response structure.
The Inner <saml:Assertion> element (Enveloped): Protects identity claims even if extracted and forwarded.
Both Elements: Highly recommended for enterprise defense against XML Signature Wrapping (XSW).

Microsoft Entra ID signs both the Assertion and the Response depending on Enterprise App configuration settings.

Module 5

5. Subject Identification & NameID Formats

Choosing the appropriate user identifier format in Microsoft Entra ID.

NameID Format URI	Example Value	Use Case / Behavior
urn:...:nameid-format:emailAddress	sanjay.dubey@outlook.com	Standard corporate email. User-friendly; vulnerable to re-assignment if employee departs and new user takes email.
urn:...:nameid-format:persistent	G-9842a-194fa-91b...	Pairwise pseudonym string permanently assigned to the user for this specific SP. Protects privacy across disparate vendors.
urn:...:nameid-format:transient	T-48194-e81a-...	Temporary random session string discarded upon logout. Best for anonymous survey portals or temporary access.
urn:...:nameid-format:unspecified	NTMS\sdubey	Domain-qualified username or custom corporate employee identifier. Default fallback in many legacy on-prem systems.

Module 6

6. Microsoft Entra ID Enterprise App Integration Playbook

Exact step-by-step Azure Portal settings for production SAML 2.0 deployment.

Basic SAML Configuration Parameters

Identifier (Entity ID):

https://saml.ntmscloud.in/saml/metadata

Strictly matches the <saml:Issuer> of AuthnRequest and AudienceRestriction.

Reply URL (Assertion Consumer Service URL):

https://saml.ntmscloud.in/saml/acs

Endpoint where Microsoft Entra ID HTTP-POSTs the SAMLResponse.

Sign-on URL (Optional):

https://saml.ntmscloud.in/

Where users land when launching the app from Office 365 or My Apps portal.

Signing Certificate & Claim Rules

SAML Signing Certificate:

Downloaded as NTMS-APP-SAML.cer. Valid for 3 years. Pinned locally on the SP.

Signing Option & Algorithm:

Set to Sign SAML response and assertion using SHA-256 (deprecating legacy SHA-1).

Attributes & Claims Mapping:

Map user.userprincipalname → Unique User Identifier, and emit App Roles as roles claim for RBAC.