SAML 2.0 (Security Assertion Markup Language) remains the dominant protocol for enterprise Single Sign-On, used by thousands of organizations to connect their workforce to hundreds of applications. While OpenID Connect is preferred for modern web applications, SAML is essential knowledge for any IAM professional because it powers the majority of enterprise software integrations. In this lab, you'll build a complete SAML SSO implementation from scratch, understanding both the Identity Provider (IdP) and Service Provider (SP) sides of the equation.
SAML 2.0 is an XML-based open standard for exchanging authentication and authorization data between parties—specifically, between an Identity Provider (IdP) and a Service Provider (SP). When you click "Login with SSO" or "Login with Corporate Account" on enterprise software, you're almost always using SAML. Understanding SAML is essential because it connects enterprise identity systems (like Active Directory, Okta, or Azure AD) to thousands of SaaS applications (Salesforce, Workday, ServiceNow, etc.). In this lab, you'll configure both sides of a SAML integration, gaining the skills to troubleshoot SSO issues that plague enterprise IT teams daily.
You're the IAM Engineer at GlobalCorp, and the IT Director has a challenge:
"We just acquired three new SaaS applications—Salesforce for sales, Workday for HR, and ServiceNow for IT service management. Each has its own login, and employees are drowning in passwords. We need Single Sign-On so employees can access all three with their corporate credentials. The vendors say they support SAML. Can you make this work?"
Before implementing SAML, you must understand its components and how they work together. SAML is more complex than OIDC because it predates modern web architecture and uses XML rather than JSON. However, this complexity provides features that OIDC lacks, particularly around enterprise federation scenarios.
SAML (Security Assertion Markup Language) is an XML-based framework for communicating authentication, authorization, and attribute information. Key characteristics:
The system that authenticates users and issues SAML assertions. Examples: Okta, Azure AD, Keycloak, Ping Identity. The IdP is the "source of truth" for user identity.
The application that users want to access. The SP trusts the IdP to authenticate users. Examples: Salesforce, Workday, AWS Console, any SAML-enabled app.
The human or system seeking access to the Service Provider. The Principal authenticates at the IdP and receives an assertion to present to the SP.
The XML document containing authentication and attribute statements. Signed by the IdP, verified by the SP. The "proof" that the user authenticated successfully.
| Component | Description | Purpose |
|---|---|---|
| Assertion | XML document with authentication/attribute statements | Carries identity information from IdP to SP |
| Protocol | Request/response message formats | Defines how to ask for and receive assertions |
| Bindings | How SAML messages travel (HTTP POST, Redirect) | Transport mechanisms for SAML messages |
| Profiles | Combinations of assertions, protocols, and bindings | Complete use cases like Web Browser SSO |
| Metadata | XML describing IdP/SP capabilities and certificates | Establishes trust between parties |
User clicks login or accesses protected resource at SP (e.g., salesforce.com)
SP creates XML request asking IdP to authenticate user, redirects browser to IdP
User enters credentials at IdP login page (username/password, MFA, etc.)
IdP creates signed SAML assertion with user identity and attributes
IdP returns HTML form that auto-submits SAML response to SP's ACS URL
SP verifies signature, checks conditions, extracts attributes, logs user in
A SAML assertion contains three types of statements:
Critical assertion elements include:
| Aspect | SAML 2.0 | OpenID Connect |
|---|---|---|
| Data Format | XML | JSON (JWT) |
| Transport | HTTP Redirect, POST | HTTP REST APIs |
| Token Size | Large (XML verbose) | Compact (Base64 JWT) |
| Best For | Enterprise SSO, legacy apps | Modern web/mobile apps |
| Mobile Support | Poor (XML parsing heavy) | Excellent (JSON native) |
| Adoption | Enterprise SaaS (Salesforce, Workday) | Consumer apps (Google, Facebook) |
This lab builds on LAB 5's Keycloak deployment. We'll add a Python Flask application as a SAML Service Provider, demonstrating the complete SSO flow.
| Component | Requirement | Purpose |
|---|---|---|
| LAB 5 Environment | Keycloak running on port 8080 | SAML Identity Provider |
| Docker | Docker 20.10+ | Container runtime |
| Python | Python 3.9+ (in container) | SAML SP application |
Configure Keycloak to issue SAML assertions for Service Provider applications.
Keycloak can act as both an OIDC and SAML Identity Provider. In this module, we'll create a SAML client configuration that defines how Keycloak will issue SAML assertions to our Service Provider application.
Ensure your LAB 5 Keycloak environment is running with the techstart realm configured.
Local MachineCreate a new client configured for SAML protocol. This represents our Service Provider in Keycloak.
Keycloak ConsoleFine-tune the SAML client settings for proper SSO behavior.
Keycloak ConsoleExport Keycloak's SAML metadata, which the Service Provider needs to trust the IdP.
Keycloak ConsoleDownload and examine the IdP metadata to understand its structure.
Local MachineKeycloak is now configured as a SAML Identity Provider. In Module 2, we'll create the Service Provider application.
Create a Python Flask application that authenticates users via SAML SSO.
A SAML Service Provider is any application that delegates authentication to an Identity Provider. We'll build a Flask application using the python3-saml library, which handles SAML message parsing, signature validation, and session management.
Create the main Flask application with SAML authentication endpoints.
Local MachineNameID: {{ nameid }}
Session Index: {{ session_index }}
{{ attributes }}
Create the python3-saml settings files that define SP and IdP configuration.
Local MachineExtract the signing certificate from Keycloak's metadata and add it to the SP configuration.
Local MachineCreate Docker configuration to run the Flask SAML SP application.
Local MachineThe SAML Service Provider application is configured. In Module 3, we'll establish trust and test the SSO flow.
Build and test the complete SAML SSO flow.
Trust in SAML is established through metadata exchange. Each party provides an XML document describing its endpoints, entity ID, and certificates. This module focuses on building and deploying the complete solution.
Retrieve and examine the SP metadata, which can be provided to IdP administrators.
Local MachineTest the complete SAML Single Sign-On flow from SP to IdP and back.
Web BrowserTest SAML Single Logout to end sessions at both SP and IdP.
Web BrowserThe SAML SSO flow is working! In Module 4, we'll configure attribute mapping.
Map IdP user attributes to SAML assertion claims for SP consumption.
SAML assertions can carry user attributes beyond just the NameID. These attributes allow the SP to know user details like email, name, groups, and roles without querying a separate directory. Proper attribute mapping is essential for SP applications to function correctly.
Login again and verify attributes appear in the SAML assertion.
Web BrowserUser attributes are now flowing from IdP to SP in SAML assertions.
Implement cryptographic protections for SAML messages.
In production SAML deployments, messages must be signed (for authenticity) and optionally encrypted (for confidentiality). This module covers the security configurations that make SAML production-ready.
Create a certificate for the Service Provider to sign requests and decrypt assertions.
Local MachineAdd the SP certificate to the SAML configuration.
Local MachineThe SP now has certificates for signing and encryption capabilities.
Configure multiple applications to use the same Identity Provider.
Enterprise environments typically have dozens or hundreds of applications using a single IdP. This module demonstrates how to add additional Service Providers and discusses IdP discovery for users who belong to multiple organizations.
Test IdP-initiated SSO where users start at the IdP portal.
Web BrowserYou've learned how to configure multiple Service Providers with a single Identity Provider.
SAML implementations have been the target of numerous attacks. Understanding these vulnerabilities is essential for building secure SSO systems.
Attacker modifies SAML response to inject malicious assertions while keeping the valid signature.
Attacker intercepts SAML response, moves signed assertion, and adds unsigned assertion with elevated privileges. Vulnerable parsers validate the wrong element.
Attacker captures and replays a valid SAML response to gain unauthorized access.
SP accepts assertions intended for other Service Providers.
Attacker injects XML comments to bypass NameID validation.
SAML troubleshooting often requires decoding Base64-encoded messages and examining XML structures. Here are common issues and diagnostic approaches.
Cause: SP cannot verify IdP signature
Cause: ACS URL in SP doesn't match what IdP expects
Cause: Attribute mappers not configured
You've built a complete SAML SSO implementation, understanding both the IdP and SP sides of the federation.