SAML Integration Overview

JRNI Updated by JRNI

JRNI supports SAML (Security Assertion Markup Language) single sign-on, letting your users authenticate into JRNI Studio or customer booking journeys with your organisation’s existing identity provider — Microsoft ADFS, Okta, Azure AD, or Salesforce

With SAML, your users never need a separate JRNI username and password. Their identity is verified by your own authentication system and securely passed to JRNI.

How it works

SAML authentication involves three parties:

Party

Role

Identity Provider (IdP)

Your authentication system — Okta, Azure AD, Salesforce, ADFS. This is where users actually log in.

Service Provider (SP)

JRNI — the application your users want to reach.

User

The staff member or customer signing in to JRNI.

Authentication flow

A SAML login can be initiated from either side — your identity provider, or JRNI.

IdP-initiated — the user starts at your identity provider
  1. User — Your user signs in to your identity provider, or already has an active session.
  2. IdP — The IdP builds a signed SAML response containing the user’s identity attributes.
  3. IdP → JRNI — The response is POSTed to JRNI’s Assertion Consumer URL.
  4. JRNI — JRNI validates the response using the certificate or fingerprint you configured.
  5. Signed in — The user is matched (or provisioned) and redirected into JRNI with an active session.
SP-initiated — the user starts at JRNI
  1. User — Your user opens JRNI — the Studio login page or a booking journey link.
  2. JRNI → IdP — JRNI redirects them to your identity provider’s SSO Target URL.
  3. IdP — The user authenticates with your IdP, or is already in an active session.
  4. IdP → JRNI — The identity provider returns a signed SAML response to JRNI.
  5. Signed in — JRNI validates the response, matches the user, and grants access.

Single Logout (SLO)

JRNI also supports SAML Single Logout. When configured, logging out of JRNI ends the session with your identity provider too — and vice versa, if your IdP supports it.

Supported response formats

JRNI accepts any combination of a signed or unsigned response with the four assertion types below — eight combinations in all.

Response

Unsigned assertion

Signed assertion

Encrypted assertion

Encrypted + signed

Unsigned response

✅

✅

✅

✅

Signed response

✅

✅

✅

✅

For extra security, you can optionally require signed and/or encrypted assertions in your JRNI SAML settings.

SAML assertion attributes

These are the attributes JRNI expects inside the SAML assertion. The ones you include determine whether a user can be looked up (authenticated) and/or created (provisioned).

Member (customer) attributes

Attribute

Lookup

Create

Required

Notes

member_id

✅

—

1+ lookup

JRNI internal member ID (integer)

email

✅

✅

1+ lookup

Valid email address

login_id

✅

—

1+ lookup

JRNI internal login ID (integer)

reference

✅

✅

1+ lookup

Your external reference (e.g. employee ID)

first_name

—

✅

Provisioning

Text

last_name

—

✅

Provisioning

Text

mobile_number

—

✅

Optional

Mobile phone number

phone_number

—

✅

Optional

Landline phone number

mobile_prefix

—

✅

Optional

Country dialling code (e.g. 44)

phone_prefix

—

✅

Optional

Country dialling code (e.g. 44)

membership_level_id

—

✅

Optional

Integer — the membership tier ID

member_type

—

✅

Optional

1 = Member (default), 2 = Contact

password

—

✅

Optional

Text — sets the initial password on creation

To look up a member, the assertion must include at least one of member_id, email, login_id, or reference.

Admin (staff / user) attributes

Attribute

Authenticate

Create

Required

Notes

user_id

✅

—

1+ lookup

JRNI internal user ID (integer)

email

✅

✅

Required

Valid email — used for both lookup and provisioning

reference

✅

—

1+ lookup

Your external reference string

first_name

—

✅

Provisioning

Text

last_name

—

✅

Provisioning

Text

role

—

✅

Optional

1 Owner · 5 Admin · 7 User (default) · 9 Call Centre

company_id

—

✅

Provisioning

The JRNI company ID the user should be assigned to

company_reference

—

✅

Provisioning

The JRNI company external id the user should be assigned to

To look up an admin user, the assertion must include at least one of user_id, email, or reference.

Provisioning — how JRNI decides

If your assertion carries enough attributes, JRNI can create the user record on first login. Here’s the logic JRNI applies to every incoming assertion:

  1. Can the user be identified? — the assertion includes a lookup attribute (e.g. email or reference).
    • No → Authentication fails.
    • Yes → continue.
  2. Does the user already exist in JRNI? — JRNI matches the lookup attribute against existing records.
    • Yes → Authenticate & sign in.
    • No → continue.
  3. Are provisioning attributes present? — members need first_name + last_name; admins also need company_id.
    • Yes → Create the record, then sign in.
    • No → Fails; the user must already exist in JRNI.

To provision a member: email or reference for lookup, plus first_name and last_name.

To provision an admin: email, first_name, last_name, andcompany_id or company_referece

SAML connection settings

Configured in JRNI Studio under Settings › Advanced Settings › SAML Settings.

Setting

Description

Name

A friendly name for this SAML connection.

SP Entity ID (Issuer) (Required)

Unique identifier for your IdP. Must match the Audience / Issuer field in your IdP configuration.

IdP SSO Target URL

Where JRNI sends users to authenticate (SP-initiated login).

Customer URL

Where your IdP redirects members after authentication (customer journey).

Admin URL

Where your IdP redirects admin users after authentication (Studio).

IdP SLO Target URL

The URL for single logout (SP-initiated).

SLO Customer URL

Where members are redirected after logout.

SLO Admin URL

Where admin users are redirected after logout.

IdP Certificate

Your IdP’s X.509 certificate in PEM format. Used to validate signed responses.

Secondary Certificate

A backup certificate for seamless rotation when the primary expires.

Certificate Fingerprint

The SHA1 fingerprint of the IdP certificate (alternative to the full certificate).

Signed Assertion

When enabled, JRNI requires assertions to be digitally signed.

Encrypted Assertion

When enabled, JRNI requires assertions to be encrypted using JRNI’s public certificate.

You must provide either the IdP Certificate or the Certificate Fingerprint. If both are supplied, the full certificate takes precedence.

URLs JRNI provides

Once a SAML connection is created, JRNI gives you these URLs to configure in your identity provider:

URL

Purpose

Assertion Consumer URL

Where your IdP should POST the SAML response after authentication.

Metadata URL

Your IdP can import this to auto-configure the connection.

SP Connection Initialisation URL

Used for SP-initiated login flows.

Multiple SAML connections

JRNI supports multiple SAML connections on a single company — useful when different user populations use different identity providers (for example, one IdP for staff and another for customers).

How did we do?

Contact