SAML SSO Configuration Guide for Enterprise Apps

This article provides an overview of the Security Assertion Markup Language (SAML) protocol and offers a step-by-step guide to configuring a SAML 2.0 enterprise application within Hexnode IdP.

Overview of SAML authentication

Security Assertion Markup Language (SAML) is an open, XML-based standard used for exchanging authentication and authorization data between parties. In the context of modern enterprise identity and access management (IAM), SAML is the backbone of Single Sign-On (SSO). It shifts the burden of credential management away from individual applications and centralizes it within a secure, dedicated identity system.

The SAML transaction primarily involves two entities:

Identity Provider (IdP): The system that holds the user identities and verifies their credentials. It is responsible for authenticating the user and asserting their identity to other systems.
Service Provider (SP): The target application or service the user is trying to access (e.g., Salesforce, Slack, or Google Workspace). The SP trusts the IdP to handle authentication.

Instead of users memorizing separate passwords for dozens of applications, they log in once to the IdP. Upon successful authentication, the IdP sends a digitally signed XML document called a SAML assertion to the SP. This assertion acts as trusted proof of identity, instructing the SP to grant the user a secure session.

Hexnode IdP as the Identity Provider

Within this architecture, Hexnode IdP serves as your authoritative Identity Provider. Integrating an application with Hexnode IdP using the SAML 2.0 protocol establishes a secure trust relationship between your directory and the third-party Service Provider.

When a user attempts to access an integrated application, Hexnode IdP validates their credentials. Once verified, Hexnode IdP generates and securely passes an identity assertion—a digital “passport”—to the Service Provider. This allows the user to access authorized applications without navigating additional login prompts.

Furthermore, Hexnode IdP allows you to pair SAML authentication with SCIM 2.0 (System for Cross-domain Identity Management) provisioning. While SAML handles the “login” event, SCIM automates the continuous lifecycle of the user account. Changes made in Hexnode IdP can automatically trigger the creation, update, synchronization, and deactivation of user accounts within the target application, ensuring organizational alignment and reducing manual IT overhead.

When to use SAML authentication

SAML is the traditional, enterprise-grade standard for identity federation. You should choose SAML when:

Integrating established enterprise software: SAML is universally supported by the vast majority of major B2B SaaS platforms, enterprise applications, and legacy web services.
Relying on rich identity data exchanges: Because SAML utilizes comprehensive XML documents, it is highly effective at passing detailed user attributes, roles, and authorization data alongside the primary authentication event.
Meeting strict organizational compliance: SAML provides highly configurable security parameters (such as structured token signing and encryption) that are often required to meet rigid corporate security and compliance frameworks.

Configure a SAML 2.0 application in Hexnode IdP

The following steps outline how to initialize a SAML application, configure SSO settings, enable SCIM automated provisioning, and assign user access.

Step 1: Initialize the application

First, create the application container within the portal.

Log in to the Hexnode IDP portal.
Navigate to Applications > MyApps.
Click + Add Apps.
Select SAML 2.0 as the protocol.
Click the edit icon next to Untitled Application to rename the application.
(Optional) Upload a logo for quick visual recognition.
Click Save.

Step 2: Configure SAML Single Sign-On (SSO)

Define how Hexnode IDP securely passes identity information to the application by providing the expected endpoint and formatting details.

In the configuration wizard, provide the following details:
1. ACS URL: Enter the Assertion Consumer Service URL. This is the exact endpoint where the application expects to receive the SAML response. Note that, if entered value is incorrect, the assertion will not reach its destination and login will fail.
2. Entity ID: Enter the globally unique identifier that represents the Service Provider. This ensures the assertion is generated exclusively for this application.
3. Audience URI: Define the intended recipient of the SAML assertion. This is often identical to the Entity ID and serves as an additional validation check.
4. Name ID Format: Select how the user is identified inside the SAML assertion:
  1. Email Address: Select this if the application uses an email address as the unique username.
  2. Unspecified: Select this if the Service Provider does not mandate a specific predefined format type.
  3. Persistent: Select this for applications that require a stable, unique identifier that remains constant across sessions, even if attributes like email change.
5. Logout URL: Enter the Single Logout (SLO) endpoint for the application. Configuring this ensures that when a user logs out of the application or Hexnode IDP, their session is securely terminated across all connected services.
After entering the required details, click Next.

Step 3: Automate user lifecycle with SCIM 2.0 provisioning

If you wish to automatically sync user accounts between Hexnode IdP and the Service Provider, configure the SCIM connection parameters.

Provide the SCIM 2.0 Endpoint URL and the secure Authorization Token.
Select the required Provisioning Actions (Create Users, Update Users, Deactivate Users, Sync Groups).
Configure the Synchronization Schedule by setting a specific Schedule Sync time and Frequency (Daily, Weekly, or Monthly).
Configure the User Attribute Mapping and Group Attribute Mapping to align Hexnode IdP fields with the application’s required schema.
Click Next.

Note:

For comprehensive instructions on configuring automated provisioning, refer to the article: Configure SCIM Provisioning in Hexnode IdP.

Step 4: Manage user and group assignments

In the Assignments section, define which identities are authorized to authenticate into the application. You can browse your directory and explicitly Include or Exclude specific users or groups to control access based on your organization’s requirements. After defining the initial access rules, click Next.

Note:

For comprehensive instructions on configuring and modifying access rules, refer to the article: Assign Users/Groups to Applications for Enterprise Single Sign-On.

Step 5: Review the application

On the Review page, verify the summary of your:
1. SAML Single Sign-On settings
2. SCIM provisioning configuration
3. User and group assignments
If adjustments are necessary, click Edit next to the corresponding section.
Click Create to finalize the integration.

The application is now active and can be managed or modified at any time under Applications > My Apps.

Frequently Asked Questions

What exactly is a SAML Assertion?

A SAML assertion is the digitally signed XML document sent from the Identity Provider (Hexnode IdP) to the Service Provider. Think of it as a digital passport. It contains trusted, verified information about the user’s identity (like their email address and group memberships) and proves to the application that the user has successfully logged in.

What happens if my ACS URL or Entity ID is incorrect?

If either of these values is wrong, the SAML SSO login will fail.

The ACS URL acts as the exact mailing address where Hexnode IDP sends the “login approved” assertion. If there is a typo in the URL, the assertion is sent to the wrong destination, and the application will not grant access.
The Entity ID is how the application securely identifies itself. If the Entity ID in Hexnode IDP doesn’t perfectly match what the application expects, the app will reject the login attempt, assuming the assertion was meant for a different service.

How do I know which Name ID Format to choose?

The required Name ID Format depends entirely on the Service Provider (the application you are integrating). You should consult the specific application’s SSO setup documentation. Most modern SaaS applications use Email Address as the standard identifier, but some specific or legacy systems may require a Persistent or Unspecified format.

Why do I need SCIM if SAML already logs users in?

While SAML securely handles authentication, it cannot fully govern a user’s lifecycle inside the application. For a SAML login to succeed, a corresponding user profile must exist in the Service Provider’s database. While you might rely on SAML Just-In-Time (JIT) provisioning to create an account upon the first login, JIT cannot automatically deactivate accounts. Consequently, when an employee leaves the organization, SAML prevents them from logging in, but their orphaned account remains active in the application—often consuming a paid license and creating compliance gaps. SCIM solves this by automatically provisioning, synchronizing, and deactivating accounts in real-time based on your directory.