This chapter covers Security Assertion Markup Language (SAML) and Single Sign-On (SSO), two foundational concepts in identity and access management. For the SC-900 exam, approximately 10–15% of questions touch on federation protocols, SSO, and authentication mechanisms. Understanding SAML’s role in enabling SSO is critical for scenarios involving Azure AD, third-party SaaS apps, and hybrid identity. This chapter will explain the SAML protocol flow, key components, configuration details, and common exam traps.
Jump to a section
Imagine a hotel guest (the user) who wants to enter the gym (a cloud application). Instead of carrying a separate key for every facility, the hotel issues a single key card (the SAML token) at check-in. The guest presents the key card to the gym door (the service provider). The gym door scans the card, sees it was issued by the front desk (the identity provider), and verifies the digital signature on the card against the front desk’s public key. The gym door does not need to check the guest’s identity again—it trusts the front desk’s authentication. The key card contains the guest’s room number (user attributes) and an expiration time (validity period). If the guest tries to enter the pool after checkout, the card is rejected because it is expired. The front desk never gives the guest a separate key for each facility; instead, it issues one card that multiple facilities accept. This eliminates the need for the guest to log in separately to the gym, pool, or business center—just one check-in (authentication) grants access to all permitted areas (SSO).
What is SAML and Why Does It Exist?
Security Assertion Markup Language (SAML) is an XML-based open standard for exchanging authentication and authorization data between an identity provider (IdP) and a service provider (SP). It was developed by OASIS (Organization for the Advancement of Structured Information Standards) and is currently defined by SAML v2.0, which is the version most widely implemented in enterprise environments. The primary purpose of SAML is to enable Single Sign-On (SSO) – allowing a user to authenticate once with an IdP and then access multiple SPs without re-entering credentials.
Before SAML, each application maintained its own user directory and authentication mechanism. Users had to remember separate usernames and passwords for every app, leading to password fatigue and increased help-desk calls for password resets. SAML solves this by decoupling authentication from application authorization. The IdP handles authentication and asserts the user’s identity to each SP via a digitally signed SAML assertion.
How SAML SSO Works – Step-by-Step Mechanism
The SAML SSO flow typically involves an SP-initiated or IdP-initiated sequence. The most common is SP-initiated (also called SP redirect). Here is the detailed flow:
User requests a resource at the SP (e.g., https://app.example.com).
SP generates an AuthnRequest – an XML message that includes the SP’s entity ID, the desired NameID format (usually persistent or email), and the Assertion Consumer Service (ACS) URL where the IdP should send the assertion.
SP redirects the user to the IdP’s Single Sign-On URL (e.g., https://idp.example.com/sso) with the AuthnRequest embedded as a query parameter (HTTP Redirect binding) or posted via HTML form (HTTP POST binding).
User authenticates to the IdP – typically via username/password, MFA, or integrated Windows authentication. The IdP may already have an existing session (SSO), in which case authentication is skipped.
IdP generates a SAML assertion – an XML document containing the user’s identity (NameID), attributes (e.g., email, role), and authorization decisions. The assertion is signed with the IdP’s private key. It may also be encrypted for additional confidentiality.
IdP sends the assertion to the SP’s ACS URL via HTTP POST (most common) or artifact binding.
SP validates the assertion – checks the signature using the IdP’s public key, verifies the assertion’s validity period (NotBefore/NotOnOrAfter timestamps), and ensures the audience (the SP’s entity ID) matches.
SP establishes a local session (e.g., an HTTP cookie) and grants the user access to the requested resource.
Key Components, Values, Defaults, and Timers
- Identity Provider (IdP): The system that authenticates the user and issues assertions. In Azure AD, the IdP is Azure AD itself.
- Service Provider (SP): The application or service that trusts the IdP’s assertions and grants access. Examples: Salesforce, Workday, AWS.
- SAML Assertion: The XML document that carries authentication and attribute information. It contains:
- <Issuer>: The IdP’s entity ID (a URI, e.g., http://idp.example.com/adfs/services/trust).
- <Subject>: The user identifier (NameID).
- <Conditions>: Validity constraints – NotBefore (default: current time minus a few minutes for clock skew), NotOnOrAfter (default: typically 8 hours for Azure AD, configurable).
- <AttributeStatement>: Optional user attributes like email, role, group.
- <AuthnStatement>: Authentication context (e.g., password, smart card).
- NameID Format: The format of the user identifier. Common values:
- urn:oasis:names:tc:SAML:1.1:nameid-format:emailAddress (email)
- urn:oasis:names:tc:SAML:2.0:nameid-format:persistent (opaque persistent ID)
- urn:oasis:names:tc:SAML:1.1:nameid-format:unspecified (any)
- Bindings: How SAML messages are transported.
- HTTP Redirect: AuthnRequest sent as query parameter (GET). Simple but limited to 2048 characters.
- HTTP POST: Assertion sent as base64-encoded XML in an HTML form (POST). Supports larger payloads.
- Artifact: A reference token is sent instead of the full assertion; SP retrieves the assertion via backchannel.
- Endpoints:
- IdP SSO URL: Where the SP sends the AuthnRequest (e.g., https://idp.example.com/sso).
- ACS URL: Where the IdP sends the assertion (e.g., https://sp.example.com/acs).
- Signing and Encryption:
Assertions are signed with the IdP’s private key. SP validates with the IdP’s public certificate.
Assertions can be encrypted using the SP’s public key. Only the SP can decrypt with its private key.
Default Timers:
Azure AD SAML token lifetime: 8 hours (configurable via PowerShell or Azure AD settings).
Clock skew tolerance: Typically 5 minutes (NotBefore minus 5 minutes).
Configuration and Verification Commands
Configuring SAML SSO in Azure AD involves:
Adding a non-gallery enterprise application.
Configuring the SAML base URL (ACS URL), identifier (entity ID), and Reply URL.
Downloading the IdP metadata XML (contains the IdP’s public certificate, SSO URL, and logout URL).
Uploading the SP metadata or manually entering endpoints.
Verification commands (PowerShell):
# Get Azure AD SAML token signing certificate
Get-AzureADTrustedCertificateAuthority | Where-Object {$_.TrustedIssuer -eq "urn:your-issuer"}
# Set token lifetime (example: 12 hours)
Set-AzureADApplication -ObjectId <app-object-id> -TokenLifetimePolicy @{TokenLifetime="12:00:00"}How SAML Interacts with Related Technologies
OAuth 2.0 and OpenID Connect: SAML is primarily for enterprise SSO with XML assertions. OAuth 2.0 is a delegation protocol (authorization), while OpenID Connect (OIDC) is an authentication layer on top of OAuth 2.0 using JSON Web Tokens (JWT). SAML is still dominant for on-premises apps and federated identity (e.g., ADFS).
WS-Federation: Another Microsoft-centric federation protocol used in ADFS. SAML is more industry-standard.
Azure AD: Azure AD acts as an IdP for SAML 2.0 applications. It supports both SP-initiated and IdP-initiated SSO. Azure AD can also act as an SP when federated with external IdPs (e.g., ADFS).
ADFS: Active Directory Federation Services (ADFS) is an on-premises IdP that supports SAML 2.0. Azure AD can federate with ADFS to enable hybrid SSO.
Exam Focus: What SC-900 Tests
SC-900 objective 2.1 covers the concepts of federation, SSO, and SAML. You need to know:
The purpose of SAML: to exchange authentication and authorization data between IdP and SP.
The difference between IdP-initiated and SP-initiated flows.
That SAML uses XML-based assertions.
That SAML supports SSO but is not the only protocol (OIDC is more modern).
Common trap: SAML is for authentication, not authorization (though it can carry authorization attributes).
Common wrong answers: - "SAML is used for mobile apps" – SAML is heavy for mobile; OIDC is preferred. - "SAML uses JWTs" – SAML uses XML, not JSON. - "SAML requires the user to authenticate to each SP" – that defeats SSO. - "SAML is a Microsoft proprietary protocol" – it is an open standard (OASIS).
Edge Cases and Exceptions
Clock skew: If the IdP and SP clocks differ by more than a few minutes, assertions may be rejected. The NotBefore timestamp includes a buffer (usually 5 minutes).
IdP-initiated SSO: The user logs into the IdP portal (e.g., MyApps) and clicks on an app tile. The IdP generates an unsolicited assertion and sends it to the SP. The SP must support IdP-initiated flows.
Single Logout (SLO): SAML supports SLO where the IdP sends a logout request to all SPs when the user logs out. Not all SPs support SLO.
Attribute mapping: The SP may expect specific attribute names (e.g., EmailAddress vs. mail). Azure AD allows custom attribute mapping.
Conclusion
SAML is a mature, widely-deployed protocol for enterprise SSO. Understanding its flow, components, and configuration is essential for the SC-900 exam and real-world identity management.
User requests SP resource
The user attempts to access a protected resource on the service provider, such as a Salesforce dashboard. The SP detects no existing session and initiates SAML SSO by generating an AuthnRequest XML message. This request includes the SP's entity ID (e.g., 'https://salesforce.com'), the desired NameID format (e.g., emailAddress), and the ACS URL where the IdP should send the assertion. The SP then redirects the user's browser to the IdP's SSO endpoint with the AuthnRequest encoded as a query parameter (HTTP Redirect binding) or embedded in an HTML form (HTTP POST binding).
IdP authenticates user
The user arrives at the IdP's login page (e.g., Azure AD sign-in). If the user already has a session cookie from a previous authentication, the IdP skips credential entry and proceeds to generate the assertion. Otherwise, the user provides credentials (username/password, MFA, etc.). The IdP validates the credentials against its directory. Once authenticated, the IdP creates a SAML assertion that includes the user's NameID (e.g., user@contoso.com), optional attributes (e.g., role = admin), and the authentication context (e.g., password). The assertion is digitally signed with the IdP's private key to ensure integrity and authenticity.
IdP sends assertion to SP
The IdP constructs an HTML form that contains the base64-encoded SAML assertion as a hidden field. The form is auto-submitted to the SP's ACS URL via HTTP POST. The SP's ACS URL is a publicly accessible endpoint that receives and processes SAML assertions. The IdP may also encrypt the assertion using the SP's public key to prevent interception. The SP receives the POST request and extracts the assertion.
SP validates assertion
The SP performs several checks on the SAML assertion: (1) Signature validation – it uses the IdP's public certificate (obtained from the IdP metadata) to verify the digital signature. (2) Timestamp validation – it checks that the current time is between NotBefore and NotOnOrAfter. A typical clock skew tolerance of 5 minutes is applied. (3) Audience restriction – it ensures the assertion's Audience element matches its own entity ID. (4) Recipient check – it verifies the assertion was sent to the correct ACS URL. If any check fails, the SP rejects the assertion and denies access.
SP grants access to user
After successful validation, the SP creates a local session for the user, typically by setting a session cookie. The user is then redirected to the originally requested resource, now authenticated. The SP may also use attributes from the assertion (e.g., role) to determine authorization. The user can now access the SP without re-authenticating until the session expires or the user logs out. If the SP supports SAML Single Logout (SLO), logging out from the SP can trigger logout from all other SPs via the IdP.
Enterprise Scenario 1: SaaS Application Federation with Azure AD
A large enterprise with 10,000 employees uses Azure AD as its identity provider. They subscribe to Salesforce, Workday, and ServiceNow. Without SAML SSO, employees would need to remember separate passwords for each app. The IT team configures each SaaS app as an enterprise application in Azure AD, uploading the SP metadata (ACS URL, entity ID) and downloading the Azure AD federation metadata. They map Azure AD attributes (e.g., user.mail) to the app's expected claims (e.g., EmailAddress). After configuration, employees log into their Azure AD portal (https://myapps.microsoft.com) and click on the app tile. Azure AD generates a SAML assertion and redirects the user to the app. The app validates the assertion and logs the user in. The SSO eliminates password-related help-desk tickets and reduces login friction. Common issues include clock skew causing assertion rejection (resolved by synchronizing time via NTP) and attribute mapping mismatches (resolved by reviewing app documentation).
Enterprise Scenario 2: Hybrid Identity with ADFS and Azure AD
A company maintains an on-premises Active Directory and uses ADFS as the IdP for internal apps. They also want to use Office 365 (Azure AD). They configure Azure AD as a federated domain with ADFS. When a user accesses Office 365, they are redirected to ADFS for authentication. ADFS issues a SAML assertion to Azure AD, which validates it and issues an OAuth token for the user. This hybrid setup allows the company to keep password policies on-premises while leveraging cloud apps. Performance considerations include load balancing ADFS servers and certificate rotation for SAML signing. Misconfiguration often involves expired signing certificates or incorrect claim rules, causing authentication failures.
Enterprise Scenario 3: B2B Collaboration with SAML
A company uses Azure AD B2B to invite external partners to access internal applications. The partner's IdP (e.g., their own ADFS) issues SAML assertions to Azure AD. Azure AD validates the assertion and maps the external user to a guest account. The partner users do not need new credentials; they authenticate to their own IdP. This reduces identity management overhead. Scalability concerns include handling multiple partner IdPs and maintaining trust relationships. Common pitfalls include not configuring attribute matching correctly (e.g., email vs. userPrincipalName) and failing to set appropriate token lifetimes.
SC-900 Objective 2.1: Describe the difference between authentication and authorization, and describe federation and SSO.
What the exam tests:
The definition of SAML as an XML-based protocol for exchanging authentication and authorization data between an IdP and SP.
That SAML enables SSO by allowing users to authenticate once with the IdP.
The basic flow: user → SP → IdP → authentication → assertion → SP → access.
That SAML is an open standard (OASIS), not Microsoft proprietary.
That SAML is commonly used in enterprise environments for web applications.
Common wrong answers and why: 1. "SAML is used for mobile app authentication" – SAML is heavy (XML) and not optimized for mobile; OAuth 2.0/OpenID Connect (using JWTs) is preferred. Candidates confuse protocols. 2. "SAML uses JSON Web Tokens (JWT)" – SAML uses XML assertions. JWT is used by OpenID Connect. This is a frequent trap because both are used for SSO. 3. "SAML requires the user to authenticate to each service provider" – This is the opposite of SSO. In SAML, the user authenticates only to the IdP; the SP trusts the IdP's assertion. 4. "SAML is a Microsoft proprietary protocol" – It is an open standard developed by OASIS. Microsoft implements it (e.g., ADFS, Azure AD), but it is not proprietary.
Specific numbers and terms that appear verbatim: - "SAML 2.0" is the version tested. - "XML assertion" is the term for the authentication data. - "Identity Provider (IdP)" and "Service Provider (SP)" are key roles. - "Federation" is the trust relationship established between IdP and SP.
Edge cases the exam loves:
The difference between IdP-initiated and SP-initiated SSO. Know that SP-initiated starts with the user accessing the SP; IdP-initiated starts at the IdP portal.
That SAML can be used for both authentication and authorization (the assertion can include attributes and authorization decisions). However, the primary use is authentication.
That Azure AD supports SAML 2.0 as an IdP and also as an SP (when federated with external IdPs).
How to eliminate wrong answers:
If the answer mentions JSON, JWT, or REST, it is likely not SAML (SAML uses XML, SOAP, HTTP redirect/POST).
If the answer implies the user authenticates to each app, it is wrong (SSO means one authentication).
If the answer says SAML is for mobile or APIs, it is wrong (OAuth/OIDC are for those).
SAML is an XML-based open standard (OASIS) for exchanging authentication and authorization data between an IdP and SP.
SAML enables Single Sign-On (SSO): users authenticate once to the IdP and access multiple SPs without re-entering credentials.
Key components: Identity Provider (IdP), Service Provider (SP), SAML assertion, NameID, ACS URL, IdP SSO URL.
Default SAML token lifetime in Azure AD is 8 hours; configurable via PowerShell.
Assertions are signed (required) and optionally encrypted; clock skew tolerance is typically 5 minutes.
SAML uses bindings: HTTP Redirect (AuthnRequest) and HTTP POST (assertion) are most common.
Common exam trap: SAML uses XML, not JSON; SAML is for web SSO, not mobile; SAML is open, not Microsoft proprietary.
Azure AD acts as both IdP (for SaaS apps) and SP (when federated with external IdPs like ADFS).
These come up on the exam all the time. Here's how to tell them apart.
SAML 2.0
Uses XML-based assertions
Heavier protocol, designed for enterprise web SSO
Primarily uses HTTP POST or Redirect bindings
Supports Single Logout (SLO) natively
Mature standard (2005), widely used in on-premises federation (ADFS)
OpenID Connect (OIDC)
Uses JSON Web Tokens (JWT)
Lighter protocol, designed for modern web and mobile apps
Uses HTTP GET/POST with OAuth 2.0 flows
SLO is less standardized, often requires back-channel
Newer standard (2014), preferred for cloud-native apps and APIs
Mistake
SAML is the same as OAuth 2.0.
Correct
SAML is an authentication protocol using XML assertions, while OAuth 2.0 is an authorization framework using tokens (often JWTs). SAML is designed for SSO; OAuth 2.0 is for delegated access. They are different standards.
Mistake
SAML only works with Microsoft products.
Correct
SAML is an open standard (OASIS) and is implemented by many vendors including Google, Salesforce, AWS, and Okta. Microsoft supports it in Azure AD and ADFS, but it is not proprietary.
Mistake
SAML assertions are always encrypted.
Correct
SAML assertions are typically signed (for integrity) but encryption is optional. The IdP can encrypt the assertion using the SP's public key, but it is not mandatory. The exam may test that signing is required, encryption is optional.
Mistake
SAML is used for mobile app authentication.
Correct
SAML is designed for web browser-based SSO. For mobile and native apps, OAuth 2.0 with OpenID Connect is preferred because they are lighter (JSON vs XML) and better suited for non-browser clients.
Mistake
The user authenticates to each service provider in SAML SSO.
Correct
In SAML SSO, the user authenticates only to the identity provider. The service provider trusts the IdP's assertion and does not require the user to re-authenticate. This is the core of SSO.
Reveal each answer, then mark whether you got it right. Score 60%+ to unlock the next chapter.
SAML is an authentication protocol that uses XML assertions to enable SSO. OAuth 2.0 is an authorization framework that uses tokens (often JWTs) to grant delegated access. SAML is designed for web browser SSO, while OAuth is for APIs and mobile apps. SC-900 tests that SAML is for authentication and OAuth for authorization, though SAML can also carry authorization attributes.
Yes, Azure AD supports SAML 2.0 as an identity provider for thousands of pre-integrated and custom enterprise applications. It also supports SAML as a service provider when federated with external IdPs like ADFS. You configure SAML SSO in the Azure portal under Enterprise applications > SAML-based Sign-on.
The default token lifetime is 8 hours. You can modify it using PowerShell or Azure AD settings (Token Lifetime Policy). The exam may ask for this value. Note that token lifetimes are configurable per application.
The Assertion Consumer Service (ACS) URL is an endpoint on the service provider that receives SAML assertions from the identity provider. The IdP sends the assertion to this URL via HTTP POST. The SP validates the assertion and establishes a session. It must match exactly what the SP expects.
While technically possible, SAML is not ideal for mobile apps because it relies on HTTP redirects and HTML forms. OpenID Connect (OIDC) is preferred for mobile due to its lightweight JSON tokens and better support for native app flows. The exam tests that SAML is typically for web SSO.
In SP-initiated SSO, the user first tries to access a service provider, which then redirects the user to the IdP for authentication. In IdP-initiated SSO, the user logs into the IdP portal first (e.g., MyApps) and clicks an app tile, which triggers the IdP to send an unsolicited assertion to the SP. Both are supported in SAML.
Single Logout allows a user to log out from all SAML-enabled applications by logging out from one. The IdP sends logout requests to all SPs that have an active session. Not all SPs support SLO. It is optional in SAML 2.0.
You've just covered SAML and Single Sign-On (SSO) — now see how well it sticks with free SC-900 practice questions. Full explanations included, no account needed.
Done with this chapter?