SAML
An XML-based open standard for exchanging authentication and authorization data between an Identity Provider (IdP) and Service Provider (SP) using assertions.
What is SAML?
SAML (Security Assertion Markup Language) is an XML-based open standard for exchanging authentication and authorization data between two parties: the Identity Provider (IdP) and the Service Provider (SP).
SAML uses assertions (XML documents) to pass identity and authorization information:
- Authentication Assertion: Confirms the user has authenticated (and how)
- Attribute Assertion: Provides user attributes (email, name, roles, department)
- Authorization Assertion: Specifies what the user is allowed to do (less common)
SAML 2.0 (released in 2005) is the current standard and is widely used in enterprise Single Sign-On (SSO) scenarios. It allows employees to log in once at their corporate IdP (Okta, Azure AD) and access multiple applications (Salesforce, Workday, Slack) without re-authenticating.
Analogy
Think of SAML like a hotel key card system. The front desk (Identity Provider) verifies your ID and gives you a key card (assertion). You then use that key card to access your room, gym, and pool (Service Providers) without showing your ID again at each place.
Types and Use Cases
- Enterprise SSO: Employees log in once via Okta/Azure AD and access Salesforce, Workday, Slack
- B2B Portals: Partners use their corporate credentials to access vendor portals via SAML
- Cloud Applications: SaaS apps (Concur, ServiceNow) integrate with corporate IdP via SAML
- Higher Education: Universities use SAML for SSO across campus systems
How it Works
<!-- SAML Authentication Request (SP -> IdP) -->
<samlp:AuthnRequest xmlns:samlp="urn:oasis:names:tc:SAML:2.0:protocol"
ID="_8e8dc5f69a98cc4c1ff3421e5ce34605"
Version="2.0"
IssueInstant="2023-01-15T12:00:00Z"
Destination="https://idp.example.com/sso">
<saml:Issuer>https://sp.example.com</saml:Issuer>
</samlp:AuthnRequest>
<!-- SAML Assertion (IdP -> SP) -->
<saml:Assertion xmlns:saml="urn:oasis:names:tc:SAML:2.0:assertion"
ID="_d71a3a8e9fcc45c9e9d248ef70493923"
IssueInstant="2023-01-15T12:00:00Z"
Version="2.0">
<saml:Issuer>https://idp.example.com</saml:Issuer>
<saml:Subject>
<saml:NameID Format="urn:oasis:names:tc:SAML:1.1:nameid-format:emailAddress">
user@company.com
</saml:NameID>
</saml:Subject>
<saml:AttributeStatement>
<saml:Attribute Name="email">
<saml:AttributeValue>user@company.com</saml:AttributeValue>
</saml:Attribute>
<saml:Attribute Name="firstName">
<saml:AttributeValue>John</saml:AttributeValue>
</saml:Attribute>
<saml:Attribute Name="role">
<saml:AttributeValue>Employee</saml:AttributeValue>
</saml:Attribute>
</saml:AttributeStatement>
</saml:Assertion>SAML vs OpenID Connect (OIDC)
SAML
OpenID Connect (OIDC)
SAML 2.0 uses XML and POST bindings (older, complex)
OIDC uses JSON and REST APIs (modern, simpler)
SAML is enterprise-focused (older, established)
OIDC is consumer + enterprise (newer, growing fast)
SAML works via browser redirects/POST
OIDC works via authorization code flow (more flexible, better mobile support)
Best Practices for SAML
- Validate signatures: Always verify the SAML assertion signature using the IdP's public certificate
- Check timestamps: Validate
NotBeforeandNotOnOrAfterto prevent replay attacks - Use HTTPS only: SAML assertions travel via browser - always use HTTPS to prevent interception
How LoginRadius Powers SAML
LoginRadius CIAM platform provides comprehensive SAML 2.0 support. As a Service Provider, LoginRadius can connect to your enterprise IdP (Okta, Azure AD, Ping) via SAML for employee authentication. As an Identity Provider, LoginRadius can issue SAML assertions for your customers to access third-party SaaS applications. Our platform handles SAML metadata, certificate management, assertion signing/validation, and supports both IdP-initiated and SP-initiated flows. LoginRadius also provides SAML test tools and detailed SAML logs for troubleshooting.
FAQs
Yes, SAML 2.0 is still widely used in enterprise environments. Many established enterprises have SAML integrations with vendors (Salesforce, Workday, etc.) that they don't want to replace. However, new implementations typically choose OIDC because: (1) JSON is easier than XML, (2) Better mobile support, (3) Simpler implementation. Many organizations support both SAML and OIDC for maximum compatibility.
Identity Provider (IdP) is the system that authenticates the user and issues SAML assertions (e.g., Okta, Azure AD, LoginRadius). Service Provider (SP) is the application that consumes the SAML assertion to log the user in (e.g., Salesforce, Workday, Slack). The IdP 'proves who you are', the SP 'grants you access to the app'.
LoginRadius supports SAML 2.0 in two ways: (1) As a Service Provider (SP) - connect to your corporate IdP (Okta, Azure AD) via SAML for employee SSO, (2) As an Identity Provider (IdP) - allow your customers to use LoginRadius as their IdP to access third-party apps via SAML. LoginRadius provides SAML metadata endpoints, certificate management, and supports both IdP-initiated and SP-initiated flows.