Feature Description - SAML



Security Assertion Markup Language (SAML) is a standards-defined protocol. The specification defines the syntax and semantics for assertions made about a subject. Subjects are typically end users of a system. SAML assertions and protocol messages are XML-encoded but rely on HTTP-based mechanisms for transport between entities.

SAML enables web-based Single Sign On (SSO). It also provides for centralized federated identity and authentication management. Microsoft Active Directory Federation Services (AD FS) is the SAML-based Identity Provider (IdP) which has been tested and which is referred to in this document. However, other IdPs may also work. AD FS is a standards-based service running on a Microsoft box that allows the secure sharing of identity information between trusted parties. In general terms, this is known as a federation. AD FS supports SAML, essentially playing the role of a SAML IdP. The LoadMaster supports SAML, playing the role of a SAML service provider. The service provider provides secure, gated access to a resource.

1.1Document Purpose

The purpose of this document is to provide information and instructions on how to configure SAML authentication with the KEMP LoadMaster.

1.2Intended Audience

This document is intended to be used by anyone who is interested in finding out further information about using SAML authentication with the LoadMaster.

2SAML Authentication Flow

When using other Edge Security Pack (ESP) authentication protocols in the LoadMaster, end users are presented with the standard KEMP login form. This is not displayed by LoadMaster when using SAML because a login form is not provided by KEMP. The LoadMaster instead redirects the client to a login form which is located at the IdP.

The LoadMaster implementation relies on protocol bindings for HTTP redirect which is used for redirections to a claims provider, alternatively known as an IdP. The LoadMaster also has a dependency on HTTP POST – the LoadMaster expects HTTP POST messages for IdP responses, where applicable.

The domain is fundamentally different to other types of SSO domain that are configurable on the LoadMaster because the LoadMaster does not interact directly with the authentication server (AD FS in this scenario). The LoadMaster redirects and informs the client to interact directly with AD FS so that the client can input the credentials that are required for authentication.

Figure 2‑1: SAML Authentication Flow

Here is a description of the flow:

  1. The client attempts to connect to the Virtual Service on the LoadMaster.
  2. The LoadMaster identifies that there is no cookie for the session. As this is a SAML-based domain – the authentication request is built.
  3. The client is informed to redirect to the IdP.
  4. The client sees the login form from the IdP federation server and enters their credentials. This interaction is between the client and the IdP. The credentials are passed between the client and the Federation Server.
  5. The IdP parses the SAML request and authenticates the user.
  6. The IdP generates the SAML response.
  7. The IdP returns the encoded SAML response to the browser in the URL.
  8. A POST request, including the SAML response is passed back to the Service Provider (the LoadMaster).
  9. The LoadMaster validates the contents of the SAML response and grants/denies access. Back-end KCD processing is performed at this point, if KCD is in use.

Logging out results in another series of events:

  1. The user signs out.
  2. The client gets logged out of the LoadMaster and redirected to the IdP again to allow the user to log back in, if necessary.
  3. A logout response is passed from the IdP to the client.
  4. A logout response is passed from the client to the LoadMaster.

3AD FS Settings

Some information is provided below on some of the key AD FS settings. The AD FS settings can be configured using the AD FS management console which is available in the Server Manager by going to Tools > AD FS Management.

3.1Terminology Differences

There is a difference in terminology between AD FS terms and SAML terms. AD FS supports SAML and implements SAML but the terminology associated with AD FS varies in comparison to the terminology that is used in the context of SAML.

Some examples of these terminology differences are provided in the table below.

AD FS Name



Security Token


A package of security information, describing a user, created and consumed during a federated access request.

Claims Provider

Identity Provider (IdP)

Partner in a federation that creates security tokens for users.

Relying Party

Service Provider (SP)

Partner in a federation that consumes security tokens for providing access to applications.


Assertion attributes

Data about users that is sent inside security tokens.

Table 3‑1: Terminology differences between AD FS and SAML

3.2Ensure the Services are Running

Before making changes to the AD FS settings, ensure the Active Directory Federation Services and Device Registration Service are running.

To do this, follow the steps below:

Figure 3‑1: Start

  1. Click the Start menu in the bottom-left corner of the screen.

Figure 3‑2: Run

  1. Type run and click the Run option.

Figure 3‑3: Services.msc

  1. Enter services.msc and click OK.

Figure 3‑4: Active Directory Federation Services

  1. Ensure the Active Directory Federation Services is running. If it is not, right-click it and click Start.

Figure 3‑5: Device Registration Service

  1. Ensure the Device Registration Service is running. If it is not, right-click them and click Start.

3.3Service Settings

Figure 3‑6: Edit Federation Service Properties

To access the Federation Service Properties, click the AD FS folder and click Edit Federation Service Properties on the right.

Figure 3‑7: Federation Service Properties

Figure 3‑8: Login form

The Federation Service display name is the corporation name. This is shown on the log on screen when the client is redirected to the form-based authentication on the IdP. In the example screenshot above, the Federation Service display name is set to samltest corporation.

The Federation Service name is the qualified server name (Fully Qualified Domain Name (FQDN)) for this federation service (AD FS).

The Federation Service identifier is the IdP entity ID, such as http://<FQDN>/adfs. This must match the IdP entity ID in the context of SAML.

Figure 3‑9: Events

In the Events tab, the first three options should be selected.

3.4Endpoint Settings

The Services > Endpoints folder contains a list of the endpoints that are served by AD FS.

Figure 3‑10: Metadata

The Metadata section contains a path to the FederationMetadata.xml file which can be imported into the LoadMaster when configuring the SAML domain. This path will form part of a full URL which includes the federation service server. Go to this URL (for example, https://<FQDN>/FederationMetadata/2007-06/FederationMetadata.xml) in a web browser to download the metadata file which can then be imported using the IdP Metadata File field in the LoadMaster. Importing this file automatically populates the IdP Entity ID, IdP SSO URL and IdP Logoff URL fields with the relevant data.

3.5Certificate Settings

All communications between the service provider and the IdP (AD FS in this case) must be secure. The certificate infrastructure must be in place on AD FS. KEMP assumes that this is in place in the case of production environments. If setting up AD FS for the first time, please ensure the correct certificate infrastructure is in place.

Figure 3‑11: Certificates

In the Certificates folder, there are certificates for service communication, token decrypting and token signing. The token signing certificate is important. When referring to tokens in AD FS, they generally map to assertions in the context of SAML. The token signing certificate is used for signing any response data from the AD FS. The LoadMaster requires this certificate to verify the signature on the service provider side (that is, on the LoadMaster side).

Export the token signing certificate from AD FS by following the steps below:

  1. Go to Services > Certificates in AD FS.
  1. Select the Token-signing certificate.

Figure 3‑12: View Certificate

  1. Click View Certificate.

Figure 3‑13: Copy to File

  1. Click Copy to File.
  2. Follow the steps in the certificate export wizard.
  3. Provide a filename for the certificate.

You must convert the certificate to a .pem format before importing it to the LoadMaster. There are many certificate converters available online. Alternatively, you can use an openssl command to perform the conversion.

Import the .pem certificate into the LoadMaster by following the steps below in the LoadMaster Web User Interface (WUI):

  1. In the main menu, go to Certificates & Security > Intermediate Certs.
  1. Click Choose File.
  2. Browse to and select the certificate file.
  3. Enter a Certificate Name and click Add Certificate.

This token signing certificate is now available to select in the IdP Certificate drop-down list in the SAML SSO domain in the LoadMaster.

3.6Claim Description Settings

The Claim Descriptions folder contains a list of all the claims that can be asked and provided for. Usually this is backed up by Active Directory. There is a mapping between LDAP attributes and the claims that can be provided by AD FS.

3.7Trust Relationships Settings

The trust relationship is about establishing trust between an IdP and a service provider. In AD FS terminology – the relying party is the service provider (the LoadMaster).

Identifiers are configured here in AD FS which are used when building request messages from the service provider.

3.7.1Ensure Active Directory is Enabled

To ensure Active Directory is enabled, click the Claims Provider Trusts folder.

Figure 3‑14: Active Directory

3.7.2Add a Relying Party Trust

To add a Relying Party Trust, follow the steps below:

Figure 3‑15: Relying Party Trusts

  1. Click the Relying Party Trusts folder.

Figure 3‑16: Add Relying Party Trust

  1. Click Add Relying Party Trust.

Figure 3‑17: Start

  1. Click Start.

Figure 3‑18: Enter data about the relying party manually

  1. Select Enter data about the relying party manually and click Next.

Figure 3‑19: Display name

  1. Enter a Display name for the Relying Party Trust and click Next.

Figure 3‑20: AD FS profile

  1. Select the AD FS profile option (this supports SAML 2.0) and click Next.

Figure 3‑21: Next

  1. Click Next and do not add a token encryption certificate. Encryption is not supported.

Figure 3‑22: Next

  1. Do not select either option on the Configure URL screen and click Next.

Figure 3‑23: Relying party trust identifier

  1. Enter the Relying party trust identifier in the form of a URL and click Add.

Figure 3‑24: Relying party identifier

  1. Click Next.

Figure 3‑25: Do not configure multi-factor authentication

  1. Select I do not want to configure multi-factor authentication settings for this relying party trust at this time and click Next.

Figure 3‑26: Permit all users to access this relying party

  1. Select Permit all users to access this relying party and click Next.

Figure 3‑27: Ready to Add Trust

  1. Click Next.
  2. Click Finish.

3.7.3Add End Points

Now, add the end points by following the steps below:

Figure 3‑28: Properties

  1. Go to the Properties of the relying party trust.
  2. Select the Endpoints tab.

Figure 3‑29: Add SAML

  1. Click Add SAML.

Figure 3‑30: Assertion Consumer Endpoint

  1. Select SAML Assertion Consumer from the Endpoint type drop-down list.
  2. Select POST as the Binding.
  3. Enter the Virtual Service FQDN in the Trusted URL text box. Then, click OK.

Figure 3‑31: Add SAML

  1. Click Add SAML again to add the logout endpoint.

Figure 3‑32: Logout endpoint

  1. Select SAML Logout as the Endpoint type.
  2. Select POST as the Binding.
  3. Enter the logout URL in the Trusted URL text box, for example https://<VirtualServiceFQDN>/<LogoutURL>.
  4. Copy the URL from the Trusted URL text box into the Response URL text box. Then, click OK.

Figure 3‑33: Endpoints

Both URLs should point towards the Virtual Service.

3.7.4Import the Certificate

Export the certificate from the LoadMaster by going to Virtual Services > Manage SSO, clicking Modify on the SAML SSO domain and clicking Download.

To import the certificate in AD FS, follow the steps below:

  1. Select the Signature tab.
  1. Click Add.
  2. Browse to and select the certificate that was downloaded from the LoadMaster.

In the context of log out processing – the service provider signs the log out request message. Therefore, on the AD FS side – there must be a certificate to verify that the signature is accurate and correct for the message that was signed on the service provider.

Figure 3‑34: Signature

  1. Click OK.

3.7.5Configure the Identifiers

Configure the identifiers by following the steps below:

  1. Select the Identifiers tab.

Figure 3‑35: Display name

  1. Enter the Display name. This value should be entered as the SP Entity ID in the LoadMaster.
  2. For the Relying party identifiers, include all possible connotations of the URL, for example http://<ID>, https://<ID>.
  3. Click OK.

3.7.6Claim Rules

Some Claim Rules must be added. In the Claim Rules, the LDAP attributes are mapped to the outgoing claim types. The LoadMaster is interested in:

  • The User-Principal-Name which maps to the UPN (which is the outgoing claim type)
  • The SAM-Account-Name (which is the typical Windows samAccountName attribute from an LDAP perspective) which maps to the Windows account name
  • The User-Principal-Name which maps to the Name ID outgoing claim type

The User-Principal-Name is important because without it – a session index is not included in the SAML response. The session index is very important to correlate an existing session and a log out operation.

These three attributes are the minimum required. The UPN is required to proceed with KCD processing on the back end.

To add these Claim Rules, follow the steps below:

Figure 3‑36: Edit Claim Rules

  1. Select the Relying Party Trusts folder.
  1. Right-click the relevant Display Name and select Edit Claim Rules.

Figure 3‑37: Claim Rules

  1. Edit the relevant rule.
  2. Add the attribute mappings.

Figure 3‑38: Permit

  1. Ensure that all users are permitted access by selecting the Issuance Authorization Rules tab.

3.8Authentication Policies Setting

Right-click the Authentication Policies folder and select Edit Global Primary Authentication.

Figure 3‑39: Edit Global Authentication Policy

Select the Primary tab. Depending on production requirements (external/internal, and so on), Forms Authentication may need to be enabled for both the Extranet and Intranet. Deselect the other options. Click OK to save the settings.

4Configure SAML Authentication in the LoadMaster

Follow the steps in the sections below to configure the options for SAML in the LoadMaster.

4.1Configure the SSO Domain

SAML SSO domains are fundamentally different from other SSO domains which can be configured on the LoadMaster. This is because the LoadMaster does not directly interact with the authentication server. In the context of SAML, the LoadMaster performs redirections. The LoadMaster asks the client to redirect to an IdP to issue some claims and get the required assertions back.

To configure a SAML-based SSO domain in the LoadMaster, follow the steps below:

  1. In the main menu of the LoadMaster WUI, go to Virtual Services > Manage SSO.

Figure 4‑1: Client Side Configuration

  1. Enter a name for the SSO domain in the Add new Client Side Configuration text box and click Add.

Figure 4‑2: SAML SSO domain

  1. Select SAML as the Authentication Protocol.
  2. Select the relevant IdP Provisioning option.

The Manual option enables you to manually input details into the IdP fields.

The MetaData File option enables you to upload an IdP MetaData File. This simplifies the configuration of the IdP attributes, including the IdP Entity ID, IdP SSO URL and IdP Logoff URL. The metadata file can be downloaded from the IdP. For further information, refer to Section 3.4. To upload the file - click Browse, navigate to and select the relevant file and click Import IdP MetaData File.

  1. Select an IdP Certificate for use in the context of assertion verification.

The certificate can be exported from the IdP and imported in the LoadMaster in the Certificates & Security section.

The IdP Certificate is very important in terms of verification of the assertions that must be contained in the SAML response that is received from the IdP. Without the certificate, verification cannot proceed.

  1. Enter the SP Entity ID and click Set SP Entity ID.

This is an identifier that is shared to enable the IdP to understand, accept and have knowledge of the entity when request messages are sent from the LoadMaster. This must correlate to the identifier of the relying party on the AD FS server.

  1. Select the relevant SP Signing Certificate option.

It is optional to sign requests that are sent in the context of logon. Currently, the LoadMaster does not sign those requests.

In the context of log off requests – it is mandatory and these requests must be signed. This is to avoid any spoofing and to provide extra security in relation to log off functionality. This ensures that users are not being hacked and not being logged off unnecessarily.

In the SP Signing Certificate field, you can choose to use a self-signed certificate or third party certificate to perform the signing.

  1. If using a self-signed certificate, click the Download button to download the certificate. This certificate must be installed on the IdP server (for example AD FS) to be added to the relying party signature.

The AD FS server requires this certificate for use of the public key to verify the signatures that the LoadMaster generates.

  1. Select the relevant Session Control option.

The IdP maximum duration value cannot be set in the LoadMaster. The value is taken from the IdP protocol. If the value is not already set in the IdP authentication response, the default value of 30 minutes is assigned as the IdP maximum duration.

  1. If using SP Session Idle Duration, enter the SP Session Idle Duration and click Set SP Idle Duration.

If using SP Session Max Duration, enter the SP Session Max Duration and click Set SP Max Duration.

4.2Configure the Virtual Service

Follow the steps below to configure the Virtual Service to use SAML authentication:

  1. In the main menu of the LoadMaster WUI, go to Virtual Services > Add New.

Figure 4‑3: Virtual Service parameters

  1. Enter a valid IP address in the Virtual Address text box.
  2. Enter the Port.
  3. Enter a Service Name.
  4. Click Add this Virtual Service.
  5. Expand the ESP Options section.

Figure 4‑4: ESP Options

  1. Select the Enable ESP check box.
  2. Select SAML as the Client Authentication Mode.
  3. Select the SAML SSO Domain.
  4. Enter any Allowed Virtual Hosts, as needed.
  5. Enter the Logoff String and click Set SSO Logoff String.

The Logoff String is important. The Logoff String has a special protocol flow associated with it in the context of SAML. Not only do you want to log out of the Service Provider on the LoadMaster, but the user also must be logged out of the IdP.

  1. Select the Server Authentication Mode.

The Server Authentication Mode can be set to None or KCD. Basic Authentication is not supported because the LoadMaster does not have access to the username and password.

  1. If using KCD as the Server Authentication Mode, please select the relevant option for Server Side configuration.

For further information on KCD, refer to the Kerberos Constrained Delegation, Feature Description.

  1. Configure any other settings as needed.

5Appendix A: Logging

There are very detailed logs available to assist in investigating issues. Some things to look out for in the logs are:

Figure 5‑1: Log example 1

  • Ensure there is a SAML domain assigned
  • An ID must be generated for the request
  • The SAML request is encoded
  • The authentication request is built up and sent back down to L7

Figure 5‑2: Log example 2

  • At some point later, a response is received
  • An XML-encoded SAML response gets parsed
  • Some of the information which is in the SAML response is displayed
  • That information is processed
  • The required pieces are extracted to perform a significant amount of verification checks

Figure 5‑3: Log example 3

  • When finished processing the XML, the verification steps begin
  • As part of the verification:

The signature is checked to ensure it is OK

The “Not On Or After” (NOOA) time is checked to ensure that time has not passed because the assertion has a lifetime associated with it

All of the IDs are checked to ensure they match. There is an original ID which is allocated as part of a request. That ID is received back as part of a response so it is checked to ensure it matches in two places in the response document.

The issuer is verified to ensure that the response is received from the IdP which was configured previously

Figure 5‑4: Log example 4

A success code is displayed in the response. That has to be successful to indicate that the user was successfully authenticated at the IdP.

The username entered when signing in is displayed

  • Next, the KCD processing occurs (if relevant)
  • Once the KCD processing is finished, the site is browsed

Figure 5‑5: Log example 5

  • At some point there is a log out operation

An operation is seen for L7 authentication SAML logout

The logout request is built

The logout request is sent to L7

The client redirects to the logout

A digest is created and there is a full query string


Unless otherwise specified, the following documents can be found at http://kemptechnologies.com/documentation.

Kerberos Constrained Delegation, Feature Description

Document History



Reason for Change



June 2016

Initial draft

First draft of document



Jan 2017

Release updates

Updated for 7.2.37 release



Mar 2017

Minor updates

Enhancements made



Was this article helpful?

0 out of 0 found this helpful