SAML (Security Assertion Markup Language)

SAML (Security Assertion Markup Language)

1. Introduction

SAML stands for Security Assertion Markup Language.

It is an XML-based open standard used for exchanging authentication and authorization-related information between different systems.

SAML is commonly used for Single Sign-On (SSO) in enterprise applications.

For example, suppose an organization uses:

• Microsoft 365
• Salesforce
• An internal HR application
• An employee management portal

Instead of asking employees to log in separately to every application, SAML allows them to authenticate through a central Identity Provider (IdP) and access multiple applications.

This is called Single Sign-On.

2. What Problem Does SAML Solve?

Consider an organization with several applications.

Without SAML

1. Employee opens the HR application and logs in.
2. Employee opens Salesforce and logs in again.
3. Employee opens another application and logs in again.
4. Every application manages its own authentication process.

This creates several problems:

• Multiple passwords to remember.
• Repeated login operations.
• Difficult user account management.
• Increased administrative overhead.
• Inconsistent authentication policies.

With SAML

1. Employee logs in through a central identity system.
2. The identity system verifies the employee.
3. The employee accesses other applications without repeatedly entering credentials, provided those applications trust the same identity provider and the SSO session is valid.

3. Important Components of SAML

SAML primarily involves two important parties.

3.1 Identity Provider (IdP)

An Identity Provider is responsible for authenticating users and issuing SAML assertions.

Examples:

• Microsoft Entra ID
• Okta
• OneLogin
• ADFS

Responsibilities:

• Authenticate users.
• Verify usernames and passwords or other authentication factors.
• Apply authentication policies.
• Generate signed SAML assertions.
• Provide authentication information to applications.

3.2 Service Provider (SP)

A Service Provider is the application that the user wants to access.

Examples:

• HR application.
• Salesforce.
• Internal employee portal.
• Enterprise web application.

Responsibilities:

• Redirect unauthenticated users to the Identity Provider.
• Receive SAML responses.
• Validate SAML assertions.
• Create an application session.
• Allow authorized users to access application resources.

3.3 Relationship Between IdP and SP

Component	Responsibility	Example
Identity Provider	Authenticates the user	Microsoft Entra ID
Service Provider	Provides the application or service	Company HR portal
User	Wants to access the application	Employee

4. How SAML Authentication Works

Consider an employee accessing a company HR portal.

The HR portal is the Service Provider, and Microsoft Entra ID is the Identity Provider.

SAML Authentication Flow

Step-by-Step Explanation

Step 1: User accesses the application

The employee opens:

https://hr.company.com

The HR application checks whether the user has an authenticated session.

If not, it starts the SAML authentication process.

Step 2: Service Provider redirects to Identity Provider

The HR application creates a SAML Authentication Request, commonly called an AuthnRequest.

It redirects the user's browser to the Identity Provider.

Step 3: Identity Provider authenticates the user

The Identity Provider checks whether the user is already authenticated.

If the user does not have an active session, the IdP asks the user to authenticate.

Authentication may involve:

• Username and password.
• Multi-factor authentication.
• Windows-integrated authentication.
• Other configured authentication mechanisms.

Step 4: Identity Provider generates a SAML Response

After successful authentication, the Identity Provider generates a SAML Response containing a SAML Assertion.

The assertion may contain information such as:

• User identifier.
• Email address.
• Username.
• Authentication information.
• User attributes.
• Group or role information, if configured.

The assertion is typically digitally signed by the Identity Provider.

Step 5: Browser sends the SAML Response to the Service Provider

The browser submits the SAML Response to the Service Provider's Assertion Consumer Service (ACS) endpoint.

Example:

https://hr.company.com/Saml/Acs

The ACS endpoint is responsible for receiving and processing SAML responses.

Step 6: Service Provider validates the SAML Response

The Service Provider validates the response and assertion.

Typical validation checks include:

• Digital signature verification.
• Issuer validation.
• Audience validation.
• Assertion expiration.
• Destination validation.
• Recipient validation.
• InResponseTo validation, when applicable.
• Conditions and subject confirmation validation.

If validation succeeds, the application trusts the authenticated identity.

Step 7: Service Provider creates an application session

The HR application creates its own authenticated session.

The employee can now access the HR portal without entering credentials again.

5. What Is a SAML Assertion?

A SAML Assertion is an XML document containing statements about a user.

It is issued by the Identity Provider and consumed by the Service Provider.

An assertion typically contains three important types of statements.

5.1 Authentication Statement

Indicates that the user has successfully authenticated.

It can include:

• Authentication method.
• Authentication time.
• Authentication context.

5.2 Attribute Statement

Contains user-related attributes.

For example:

• Email address.
• First name.
• Last name.
• Department.
• Employee ID.
• Group membership.

5.3 Authorization Decision Statement

Can express whether a subject is permitted to access a specified resource or perform an action.

This statement type is part of SAML, although many enterprise SSO integrations use authentication and attribute statements and implement application authorization separately.

Example SAML Assertion

The following is a simplified illustrative example, not a complete production SAML response.

<saml:Assertion
    xmlns:saml="urn:oasis:names:tc:SAML:2.0:assertion"
    Version="2.0"
    ID="_abc123">
    <saml:Issuer>
        https://idp.company.com
    </saml:Issuer>
    <saml:Subject>
        <saml:NameID>
            employee@company.com
        </saml:NameID>
    </saml:Subject>
    <saml:AuthnStatement
        AuthnInstant="2026-11-12T05:00:00Z">
    </saml:AuthnStatement>
    <saml:AttributeStatement>
        <saml:Attribute Name="Email">
            <saml:AttributeValue>
                employee@company.com
            </saml:AttributeValue>
        </saml:Attribute>
        <saml:Attribute Name="Department">
            <saml:AttributeValue>
                IT
            </saml:AttributeValue>
        </saml:Attribute>
        <saml:Attribute Name="Role">
            <saml:AttributeValue>
                Manager
            </saml:AttributeValue>
        </saml:Attribute>
    </saml:AttributeStatement>
</saml:Assertion>

The Service Provider extracts the required attributes after successfully validating the assertion.

Important: A real SAML response contains additional protocol elements, conditions, subject confirmation details and usually a digital signature. The example above is intentionally simplified.

6. What Is a SAML Response?

A SAML Response is the protocol message sent by the Identity Provider to the Service Provider.

It commonly contains:

• Response ID.
• Issuer.
• Status indicating success or failure.
• One or more SAML assertions.

SAML Response	SAML Assertion
Protocol message sent by the IdP.	Contains statements about the authenticated user.
Includes response status.	Includes authentication and attribute information.
May contain one or more assertions.	Is included within a response or used in other SAML protocol contexts.

7. What Is SAML Metadata?

SAML Metadata is an XML document describing an Identity Provider or Service Provider.

It helps the two parties exchange configuration information.

Typical metadata information includes:

• Entity ID.
• Single Sign-On URL.
• Single Logout URL.
• Assertion Consumer Service URL.
• Supported bindings.
• Public signing certificates.

Example Metadata Information

Metadata Field	Purpose
Entity ID	Uniquely identifies an IdP or SP.
SSO URL	Identity Provider login endpoint.
ACS URL	Service Provider endpoint receiving SAML responses.
Certificate	Used to validate digital signatures.
SLO URL	Endpoint used for Single Logout, if supported.

Metadata reduces manual configuration errors when integrating enterprise applications.

8. SAML Bindings

SAML bindings define how SAML protocol messages are transported.

HTTP Redirect Binding

Used to send SAML messages through browser redirects.

It is commonly used for sending authentication requests from the Service Provider to the Identity Provider.

HTTP POST Binding

Used to submit SAML messages through an HTTP POST request.

It is commonly used when the Identity Provider sends a SAML response to the Service Provider's ACS endpoint.

HTTP Artifact Binding

Instead of transmitting the complete SAML message through the browser, an artifact reference is sent. The receiving party retrieves the actual message through a back-channel communication.

9. SP-Initiated vs IdP-Initiated SSO

SAML supports two common SSO initiation patterns.

9.1 SP-Initiated SSO

The authentication process starts when the user accesses the Service Provider application.

Example: An employee opens the company HR portal. The portal redirects the employee to Microsoft Entra ID for authentication.

This is commonly used because the application can initiate a request and correlate the response with that request.

9.2 IdP-Initiated SSO

The authentication process starts from the Identity Provider.

Example: An employee logs into a company application dashboard and clicks the HR application icon.

The Identity Provider sends a SAML response to the HR application.

IdP-initiated SSO requires careful validation because there is no application-generated authentication request to correlate with the response.

10. SAML vs OAuth 2.0 vs OpenID Connect

These technologies are frequently discussed together, but they solve different problems.

Feature	SAML	OAuth 2.0	OpenID Connect
Primary purpose	Enterprise authentication and SSO	Authorization	Authentication built on OAuth 2.0
Format	XML	JSON-oriented protocol messages and tokens	JSON and JWT commonly used
Common token/message	SAML Assertion	Access Token	ID Token
Common usage	Enterprise browser SSO	API access delegation	Modern web and mobile login
Typical transport	Browser redirects and POST	HTTP	HTTP
Identity information	SAML Assertion	Not inherently provided by OAuth	ID Token

When to Use SAML

• Enterprise applications.
• Organization-wide Single Sign-On.
• Integrating with existing corporate identity systems.
• Applications that already support SAML 2.0.

When to Use OAuth 2.0

• Allowing an application to access an API on behalf of a user.
• Delegated authorization.
• Service-to-service authorization.

When to Use OpenID Connect

• Modern web application authentication.
• Mobile application login.
• Authentication using an external Identity Provider.
• Applications using JWT-based identity tokens.

Important: OAuth 2.0 alone is an authorization framework, not an authentication protocol. OpenID Connect adds an authentication layer to OAuth 2.0.

11. SAML Integration in ASP.NET Core

ASP.NET Core does not provide a complete built-in SAML 2.0 Service Provider implementation in the same way that it provides built-in OpenID Connect authentication middleware.

For SAML integration, applications commonly use a third-party SAML library or an identity platform that supports SAML.

One commonly used .NET library is:

• Sustainsys.Saml2

11.1 Typical Integration Architecture

11.2 Basic Configuration Concept

The application needs configuration information from the Identity Provider and its own Service Provider settings.

Typical configuration includes:

• Identity Provider Entity ID.
• Identity Provider SSO URL.
• Identity Provider signing certificate.
• Service Provider Entity ID.
• Assertion Consumer Service URL.
• Service Provider signing certificate, when required.

The exact registration code depends on the SAML library and its version. Follow the library's current documentation rather than assuming that a particular configuration API is universal.

11.3 Mapping SAML Attributes to Claims

After successful SAML validation, the application can map user attributes to ASP.NET Core claims.

SAML Attribute	ASP.NET Core Claim
Email	ClaimTypes.Email
Name	ClaimTypes.Name
Role	ClaimTypes.Role
Employee ID	Custom claim
Department	Custom claim

Example of creating claims after identity validation:

var claims = new List<Claim>
{
    new Claim(ClaimTypes.Name, "employee@company.com"),
    new Claim(ClaimTypes.Email, "employee@company.com"),
    new Claim(ClaimTypes.Role, "Manager")
};
var identity = new ClaimsIdentity(
    claims,
    "SamlAuthentication");
var principal = new ClaimsPrincipal(identity);

This example demonstrates claim construction only. In a real SAML integration, claims must be derived from the validated assertion, not hardcoded.

11.4 ASP.NET Core Authorization

Once the SAML identity is established and mapped to claims, ASP.NET Core authorization policies can be used.

Example:

builder.Services.AddAuthorization(options =>
{
    options.AddPolicy("ManagerOnly", policy =>
    {
        policy.RequireRole("Manager");
    });
});

Protect a controller:

[Authorize(Policy = "ManagerOnly")]
[ApiController]
[Route("api/reports")]
public class ReportsController : ControllerBase
{
    [HttpGet]
    public IActionResult GetReports()
    {
        return Ok("Manager reports");
    }
}

The user must have the required role claim to access this endpoint.

12. SAML Security Best Practices

SAML is used for security-sensitive authentication, so assertion validation must be implemented carefully.

1. Validate digital signatures: Verify signatures using trusted Identity Provider certificates.
2. Validate issuer: Ensure the assertion comes from the expected Identity Provider.
3. Validate audience: Ensure the assertion is intended for the current Service Provider.
4. Validate expiration: Reject expired assertions.
5. Validate destination and recipient: Ensure the response is intended for the correct endpoint.
6. Prevent replay attacks: Track assertion IDs and reject previously processed assertions within the relevant validity period.
7. Validate InResponseTo: For SP-initiated flows, correlate the response with the original authentication request.
8. Use HTTPS: Protect browser-to-application communication.
9. Protect private keys: Keep Service Provider private signing keys secure.
10. Use secure XML processing: Protect against XML External Entity (XXE) attacks and unsafe XML parsing.
11. Avoid trusting unsigned assertions: Require the signature validation appropriate to the configured SAML profile.
12. Apply authorization separately: A valid authentication assertion does not automatically mean that the user can access every application feature.
13. Manage certificate rotation: Support planned replacement of signing certificates without unexpectedly interrupting SSO.

13. SAML Single Logout (SLO)

Single Logout allows a user to sign out of multiple connected applications through a coordinated logout process.

Example:

1. Employee logs into the company Identity Provider.
2. Employee accesses the HR application.
3. Employee also accesses Salesforce.
4. Employee logs out from an application that supports SAML Single Logout.
5. The Identity Provider and participating applications coordinate logout according to their configuration.

Single Logout is not automatically guaranteed simply because SAML SSO is configured. All participating systems must support and correctly configure the relevant logout flow.

14. Advantages and Limitations of SAML

Advantages

• Enables enterprise Single Sign-On.
• Centralizes authentication.
• Reduces repeated login operations.
• Supports integration with many enterprise identity platforms.
• Supports user attributes and authentication information.
• Uses digital signatures to protect assertion integrity.

Limitations

• XML messages are more complex than common JSON-based identity protocols.
• Configuration and certificate management require care.
• Browser-based redirects and POST messages add integration complexity.
• Troubleshooting can be difficult without SAML tracing tools.
• Modern mobile and API authentication scenarios often use OpenID Connect and OAuth 2.0 instead.

15. Common SAML Interview Questions

Q1. What is SAML?

SAML is an XML-based open standard used to exchange authentication and authorization-related information between an Identity Provider and a Service Provider. It is commonly used for enterprise Single Sign-On.

Q2. What is the difference between IdP and SP?

The Identity Provider authenticates users and issues SAML assertions. The Service Provider is the application that validates the assertions and grants access.

Q3. What is a SAML Assertion?

A SAML Assertion is an XML document containing statements about a user, such as authentication information and user attributes.

Q4. What is an ACS URL?

ACS stands for Assertion Consumer Service. It is the Service Provider endpoint that receives SAML responses from the Identity Provider.

Q5. What is SAML Metadata?

SAML Metadata is an XML document containing configuration information about an Identity Provider or Service Provider, including entity IDs, endpoints and certificates.

Q6. What is SP-Initiated SSO?

It is an SSO flow where the user starts by accessing the Service Provider application, which redirects the user to the Identity Provider for authentication.

Q7. What is IdP-Initiated SSO?

It is an SSO flow where the user starts from the Identity Provider portal and selects an application to access.

Q8. What is the difference between SAML Response and SAML Assertion?

A SAML Response is the protocol message sent by the Identity Provider. It commonly contains a SAML Assertion, which carries information about the authenticated user.

Q9. What is the difference between SAML and JWT?

SAML is an XML-based protocol and assertion format commonly used for enterprise SSO. JWT is a compact token format that can represent claims and is commonly used with OAuth 2.0 and OpenID Connect. They are not direct alternatives at the same protocol level.

Q10. Can ASP.NET Core applications support SAML?

Yes. ASP.NET Core applications can integrate with SAML Identity Providers using third-party SAML libraries or an identity platform that supports SAML.

Q11. Does SAML provide authorization?

SAML can carry authorization-related information, but in typical enterprise SSO integrations, the application maps user attributes and roles into its own authorization system.

Q12. What is SAML Single Logout?

Single Logout is a mechanism that coordinates logout across an Identity Provider and participating Service Providers.

16. Summary

• SAML: XML-based standard for exchanging authentication and authorization-related information.
• IdP: Identity Provider that authenticates users.
• SP: Service Provider that provides the application.
• SAML Assertion: Contains statements about the authenticated user.
• SAML Response: Protocol message sent from the IdP to the SP.
• ACS URL: Endpoint that receives SAML responses.
• SAML Metadata: Contains identity-provider and service-provider configuration.
• SP-Initiated SSO: Login starts from the application.
• IdP-Initiated SSO: Login starts from the identity-provider portal.
• SLO: Coordinates logout across participating applications.

Real-world example: An employee logs into Microsoft Entra ID once and accesses multiple company applications without repeatedly entering credentials. SAML can provide the trust and authentication exchange that enables this enterprise Single Sign-On experience.

17. References

• OASIS SAML Standard
• Microsoft Entra Single Sign-On
• Sustainsys.Saml2 Documentation

Comments and Discussion