Skip to content
English
Submit a request
  • There are no suggestions because the search field is empty.

Authentication: Case-Insensitive Email & SAML Login Resilience

Email login and SAML assertion lookup now handle case variation reliably across API, Hub, and IdP flows

1. Purpose & Scope

This article documents the authentication robustness improvements shipped in Tiled v57.0.0, specifically addressing case-insensitive email handling for the API and Hub login flows, and SAML assertion lookup resilience for enterprise SSO customers. These changes ensure that authentication succeeds reliably regardless of the letter-case used in email addresses at login or in SAML assertions from identity providers.

Scope: All Tiled users who authenticate via email/password or SAML SSO. Tiled Library Administrators responsible for SAML configuration. Security and compliance teams reviewing access control evidence.

2. Control Objective

The control objective is to ensure that the Tiled authentication layer treats email addresses as case-insensitive identifiers — consistent with RFC 5321 (SMTP) standards and common user behavior — so that login attempts using any combination of upper and lower case for a registered email address succeed without error. Additionally, SAML user lookups must be resilient to case differences between the email address stored in Tiled and the email value asserted by the identity provider.

3. Problem Context

Email addresses are technically case-insensitive in the local part (before the @ sign) by convention, though many mail systems treat them as case-insensitive in practice. Users frequently register with one case variation (e.g., User@Company.com) but later attempt to log in with another (e.g., user@company.com). Similarly, SAML identity providers may assert an email attribute in a different case than the value stored in the Tiled user record — particularly when users were provisioned through different channels.

Prior to v57.0.0, these case differences could cause login failures or SAML authentication errors, creating a confusing access-denied experience for users who had valid accounts.

4. Changes Shipped

4.1 TD-6468 — Case-Insensitive Email for API Login

Surface

Tiled API — authentication endpoint.

Change

The API authentication endpoint now normalizes email addresses to lowercase before performing user lookup. A login attempt with any case variation of a registered email address resolves to the correct user account.

Security Impact

Case normalization is applied consistently at the API layer, preventing a class of authentication bypass or account confusion issues that could arise from case-variant email handling.

SOC 2 Criteria

CC6.1 — ensures that access controls correctly identify the authenticating user regardless of input case variation.

4.2 TD-6406 — Case-Insensitive Email for Hub Login

Surface

Tiled Hub — web application login page.

Change

The Hub login form now normalizes email input to lowercase before submitting to the authentication layer. Users entering their email in any case variation will authenticate successfully.

User Impact

Eliminates login failures for users who type their email in mixed case or whose email client auto-capitalizes the first letter on mobile devices.

SOC 2 Criteria

CC6.1 — consistent with the API change, ensuring the Hub login surface applies the same normalization logic.

4.3 TD-6418 — SAML Lookup Resilience

Surface

Tiled SAML SSO authentication flow — used by enterprise customers with IdP-managed authentication (Okta, Azure AD, Google Workspace, etc.).

Change

When a SAML assertion is received, the user lookup in the Tiled identity store now performs a case-insensitive match on the email attribute. A SAML assertion containing 'USER@company.com' will correctly resolve to the Tiled user record stored as 'user@company.com'.

Enterprise Impact

Eliminates SAML authentication failures caused by case differences between the IdP-asserted email and the Tiled-stored email. Particularly important when users were provisioned via different channels (e.g., manually created with one case, then provisioned via IdP with another).

SOC 2 Criteria

CC6.2 (Prior to Issuing System Credentials) and CC6.6 (Logical Access Security Measures) — SAML assertions are the credential mechanism for SSO users. Reliable resolution ensures access is granted to the correct, authorized user.

5. Security Considerations

Security Control: Case-insensitive email normalization is applied at the lookup/authentication layer only. Email addresses stored in the Tiled user record retain their original case for display purposes. Normalization is idempotent — applying it multiple times produces the same result — and does not affect any other user record attributes.

The following security properties are preserved by this implementation:

• One account per email address: case normalization does not create new accounts — it only resolves login attempts against existing accounts. Two users cannot register with the same email in different cases.

• No credential exposure: normalization occurs server-side after credential submission. It does not affect password handling, token issuance, or session management.

• SAML assertion integrity: the SAML assertion is not modified. Only the lookup step uses case-insensitive matching. The asserted email value is logged as received for audit purposes.

6. QA Validation

QA Scope: Authentication case-sensitivity and SAML flows were included in the v57.0.0 QA scope. Hub email case, API case, and SAML case-insensitive flows were all validated before the February 4, 2026 release.

 

Hub Login — Mixed Case

Verified: login with User@Company.COM resolves to user@company.com account.

API Login — Mixed Case

Verified: API auth with uppercase email returns valid token for the correct user.

SAML — Case Mismatch

Verified: SAML assertion with uppercase email resolves to lowercase-stored Tiled user record.

SAML — Case Match

Verified: existing SAML flows with matching case continue to function correctly.

7. Audit Evidence

• TD-6468 and TD-6406: API and Hub case-insensitive login constitute SOC 2 CC6.1 (Logical and Physical Access Controls) evidence — the authentication layer correctly identifies users regardless of input variation.

• TD-6418: SAML lookup resilience constitutes CC6.2 (Prior to Issuing System Credentials) evidence — SAML-asserted credentials are resolved correctly to the authorized user before session credentials are issued.

8. Change History

v1.0 — February 4, 2026

Initial article. All three authentication improvements shipped in Tiled v57.0.0 (TD-6468, TD-6406, TD-6418).