Skip to main content Skip to complementary content

SAML for integration with identity providers

The Security Assertion Markup Language (SAML) is an XML-based open standard for authentication and authorization. One of the key benefits of SAML is that it enables single sign-on (SSO), and thereby minimizes the number of times a user has to log on to cloud applications and websites.

Three entities are involved in the authentication process:

  • The user initiates access to an application or service.

  • The identity provider (IdP) is the trusted system for user authentication, for example, Microsoft Entra ID or Okta.

  • The service provider (SP) is the application or service the user wants to log in to, such as Qlik Cloud.

The identity provider authenticates the user and asserts the identity of the user to the service provider. This is done by exchanging digitally signed XML documents known as SAML assertions. These assertions contain information about the user, their authentication status, and potentially additional attributes. The service provider can then give the user access to their services. With SSO enabled at the identity provider, the user can access several service provider sites and applications without having to log in at each site.

Qlik Cloud Government noteSAML based IDP is not supported in Qlik Cloud Government.

SP-initiated and IdP-initiated SSO

SAML supports login flows initiated by the service provider (SP) or the identity provider (IdP).

With SP-initiated SSO, the user starts at the service provider site, but instead of logging in at the site, SSO authentication is initiated with the identity provider. For example, when a user logs in to Qlik Cloud—the service provider—the login is transferred to the identity provider, which handles the actual SSO authentication.

With IdP-initiated SSO, the user logs in directly to the identity provider and selects the application, which initiates the SSO authentication to the service provider.

Assertions

Assertions are XML-based statements, containing authentication and authorization information in a standardized format. They are generated by the identity provider and verified by the service provider.

When integrating with identity providers, you may need to configure your application to exchange SAML assertions securely. This involves setting up trust relationships, endpoint URLs, and certificate exchange.

Claims

Claims are pieces of information about a user that are asserted by the identity provider and sent to the service provider during the authentication process. SAML defines a set of standard claims, including user attributes like name and email. You can modify the claims mapping based on your application's requirements.

Metadata

The exchange of metadata between the identity provider (IdP) and service provider (SP) is essential for establishing a trust relationship and ensuring the proper functioning of the SAML protocol.

IdP metadata

The service provider setup requires metadata about the identity provider. In Qlik Cloud, you can upload this information as IdP metadata files through the Administration activity center.

The identity provider metadata includes the following details:

  • The entity ID of the identity provider.

  • The Single Sign-On (SSO) URL. This is the endpoint where the SAML authentication requests are sent by the service provider to the identity provider. It is the URL to which the user is redirected for authentication.

  • The signing certificate used by the identity provider to sign the SAML assertions it sends to the service provider.

SP metadata

To set up the configuration at the identity provider side, you need service provider metadata. You can obtain this information from the Administration activity center in Qlik Cloud.

The service provider metadata includes the following details:

  • The entity ID of the service provider.

  • The Assertion Consumer Service (ACS) URL. This is where the identity provider sends the SAML assertions after authentication.

  • The signing certificate used by the service provider to sign authentication requests it sends to the identity provider.

Learn more

Did this page help you?

If you find any issues with this page or its content – a typo, a missing step, or a technical error – let us know how we can improve!