Security Assertion Markup Language (SAML) is an XML-based markup language for exchanging authentication and authorization between an Identity Provider (IdP) and a Service Provider (SP).

SAML Authentication

As technology evolves, there has been a significant shift towards federated authentication, where the authentication process is centralized by delegating it to an identity provider (IdP). SAML is one of the important methods of implementing this centralized authentication process.

SAML is imperative to organizations increasingly relying on hosted services, as it provides a single point of authentication at the IdP.

Unlike traditional methods, SAML ensures that the credentials are not stored on multiple untrusted devices, as SAML securely verifies the user's identity.

With SAML, users do not have to remember multiple credentials for different applications. A single set of login credentials allows access to multiple applications.

SAML also reduces the overhead of maintaining hardware, software for authentication, adding authentication mechanisms within applications.

SAML Terminology

Some commonly used SAML terms are listed here for reference.


A user who is trying to access a protected resource.

All communication between the Service Provider (SP) and Identity Provider (IdP) occurs through the client’s browser.

Service Provider (SP)

An entity that hosts the protected resource and requests authentication information from the Identity Provider before granting the client access to the resource.

Identity Provider (IdP)

A trusted entity which validates the identity of the client and provides authentication services to the SP.

For example, OKTA, One lOgin, ADFS etc.


XML messages exchanged between the IdP and SP.

SAML Request

A request passed from the Service Provider (SP) to the Identity Provider (IdP) to authenticate a client.

SAML Response

An assertion the IdP passes to the SP containing information about the client.

Assertion Consumer Service (ACS)

An HTTP resource within the SP that processes SAML protocol messages and returns a cookie representing the information extracted from the message. The IdP sends the SAML response assertion to the ACS.

Entity ID

A unique string that must match in both the IdP and SP.


Configuration data used to provision an SP or IdP to communicate with each other. SAML 2.0 provides a well-defined, interoperable metadata format that entities can leverage to bootstrap the trust process.

SAML Processes

There are two types of SAML processes:

IdP-initiated SSO:

The client connects to the identity provider, gets authenticated, and then accesses the resources from the service provider.

SP-Initiated SSO:

The client connects to a service provider, which then redirects the client to the identity provider for authentication. Once successfully authenticated, the client is then redirected to the service provider which allows access to the resource.


NSX Advanced Load Balancer supports only SP-initiated SSO, with an NSX Advanced Load Balancer virtual service acting as the service provider.

SAML Bindings

The IdP and SP exchange a SAML request and a SAML response with each other through the client. The method to transport these messages is called a SAML binding. SAML supports multiple kinds of bindings.

The NSX Advanced Load Balancer virtual service acting as Service Provider supports:

  • Redirect binding to direct the client to the IdP. The SAML request is carried directly in the URL query string of an HTTP GET request.

  • POST binding to send the response to the SP. The SAML response is transmitted within an HTML form using Base64-encoded content.

SAML Assertion

A SAML assertion is the XML document the IdP sends to the SP that contains the user information. There are three different types of statements in SAML assertions:


To prove the identity of the user.

Attribute assertion

SAML attributes are passed to SP as part of the assertion to provide information about the user.

Authorization assertion

Assists the SP with information to determine whether the user is authorized to access the service or not.

SAML Authentication for Clients with NSX Advanced Load Balancer Virtual Service as Service Provider

The sequence of the request flow is as below:

  1. NSX Advanced Load Balancer is acting as a service provider. The user tries to access the resource which is hosted on NSX Advanced Load Balancer by sending GET

  2. If the user is not authenticated already, NSX Advanced Load Balancer generates a SAML request and redirects the user to identity provider SSO service to get authenticated using a 302 Redirect.

  3. The client’s browser sends a GET request to the SSO service of the IdP. The SAML request is carried directly in the URL query string of an HTTP GET request.

    For example,

  4. The IdP presents a form to the user to enter the credentials unless the user is already authenticated into IdP in a previous session within the same browser. Once the credentials are validated, the user is authenticated on the IdP level.

  5. In either case, the SSO service at IdP returns an XHTML document after the successful authentication, which includes the information needed by the SP in a SAML Response parameter. The SAML response will:

    • Indicate that it is indeed from the trusted IdP and has not been altered.

    • Indicate that the user has authenticated successfully in IdP.

    • Indicate who the user is through the Name ID, a standard attribute used in SAML assertions.

  6. The SAML Response parameter is passed on to the NSX Advanced Load Balancer ACS service from the client using a POST request.

  7. NSX Advanced Load Balancer validates the assertion and sets a cookie for the client

  8. The client sends a GET request to access the resource with the cookie that the SP provided.

  9. The client can now request the resource.