From 06cd546c3c229222fd833b7ee22a0f627e5820c7 Mon Sep 17 00:00:00 2001 From: Mahmoud Tantawy Date: Thu, 6 Aug 2026 16:15:31 +0200 Subject: [PATCH 1/2] Fix SSO session, MFA and provisioning accuracy in 13-3 MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Three corrections to the Access Controls and SSO article, verified against the production Auth0 tenant and the post-login Action: - Session Management stated that IdP session values "take precedence over Light's defaults". This is backwards: Light's session limits apply to all users including SSO users, and the IdP does not extend them. - The MFA section described only Light's internal administrative access, so customers had no indication that their own users are prompted for a second factor — including when signing in through SSO. - SSO setup did not mention that users are never auto-provisioned on first sign-in. Accounts must exist in Light beforehand or authentication is denied, which is a common go-live surprise. --- .../13-security/13-3-access-controls-sso.md | 21 +++++++++++++++++-- 1 file changed, 19 insertions(+), 2 deletions(-) diff --git a/articles/13-security/13-3-access-controls-sso.md b/articles/13-security/13-3-access-controls-sso.md index 3da173c5..f814b343 100644 --- a/articles/13-security/13-3-access-controls-sso.md +++ b/articles/13-security/13-3-access-controls-sso.md @@ -114,7 +114,18 @@ Under **Settings > Guardrails > Policies**, you can create and manage spend poli ## Multi-Factor Authentication (MFA) -Multi-factor authentication is required for all administrative and engineering access to production systems and management consoles. MFA adds a second layer of verification beyond a password, helping prevent unauthorized access even if credentials are compromised. +MFA adds a second layer of verification beyond a password, helping prevent unauthorized access even if credentials are compromised. + +Within Light, multi-factor authentication is required for all administrative and engineering access to production systems and management consoles. + +### MFA for your users + +Light also applies its own MFA step to users signing in to the application: + +- **Authenticator app**: Users verify with a one-time password from an authenticator app such as Google Authenticator. +- **Applies in addition to SSO**: Signing in through your identity provider does not replace Light's MFA step. If your identity provider also enforces MFA, users complete both. +- **Remember this device**: Users can choose to be remembered, which suppresses the prompt on subsequent sign-ins until the session reaches its inactivity or maximum lifetime (see [Session Management](#session-management)). +- **Lost devices**: Recovery codes are not enabled. A user who loses their authenticator device needs an administrator to reset their MFA enrolment. ## Session Management @@ -124,7 +135,7 @@ Light's authentication layer enforces session controls to limit exposure from un - **Absolute session lifetime**: Sessions have a maximum lifetime regardless of activity, after which a fresh sign-in is required. - **Sign-out propagation**: Signing out in Light revokes the active session at the identity layer. -Customers using SSO inherit session controls from their identity provider; values configured in the IdP take precedence over Light's defaults. +These session controls are enforced by Light for all users, including those signing in through SSO. Your identity provider governs how users authenticate, but it does not extend Light's session lifetime — once a Light session reaches its inactivity or maximum limit, the user is returned to your identity provider for a fresh sign-in. ## Account Lockout and Brute-Force Protection @@ -164,6 +175,12 @@ SSO is configured at the organization level in coordination with Light's team Light's team will configure the connection on the Auth0 backend and test it with you before going live. +### User Provisioning + +SSO controls how users authenticate — it does not create their Light accounts. Users are **not** provisioned automatically on first sign-in, so each user must already exist in Light before they can sign in through SSO. + +Create users in advance under **Business partners > Users**, using the same email address they will present from your identity provider. A user who authenticates successfully at your identity provider but has no matching Light account will be denied access. + ### SAML Configuration When setting up SAML-based SSO, you'll need to configure a new SAML application in your identity provider (e.g., Okta, Azure AD, OneLogin). Use the following callback URL: From 97744e55e9d3d0375dcda0dd943796ebb71e82c3 Mon Sep 17 00:00:00 2001 From: Mahmoud Tantawy Date: Thu, 6 Aug 2026 17:11:15 +0200 Subject: [PATCH 2/2] Address review: MFA role scope, HRM provisioning, remembered-device wording MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit - State which users are prompted for MFA. Any role beyond Reimbursement and Invoice approver requires a second factor; users limited to those two do not. Raised by @tiagoengel, who recalled Cardholder as exempt — it is not. - Distinguish HRM-based auto-provisioning (supported, via Finch) from just-in-time provisioning by the identity provider (not supported), and link to the HRM integration article. - Drop the claim that "remember this device" lapses when the Light session reaches its inactivity or maximum lifetime. Auth0 stores that choice in a separate remember-browser cookie, and the coupling is not established well enough to state in customer documentation. --- articles/13-security/13-3-access-controls-sso.md | 10 +++++++--- 1 file changed, 7 insertions(+), 3 deletions(-) diff --git a/articles/13-security/13-3-access-controls-sso.md b/articles/13-security/13-3-access-controls-sso.md index f814b343..d26465a9 100644 --- a/articles/13-security/13-3-access-controls-sso.md +++ b/articles/13-security/13-3-access-controls-sso.md @@ -124,7 +124,8 @@ Light also applies its own MFA step to users signing in to the application: - **Authenticator app**: Users verify with a one-time password from an authenticator app such as Google Authenticator. - **Applies in addition to SSO**: Signing in through your identity provider does not replace Light's MFA step. If your identity provider also enforces MFA, users complete both. -- **Remember this device**: Users can choose to be remembered, which suppresses the prompt on subsequent sign-ins until the session reaches its inactivity or maximum lifetime (see [Session Management](#session-management)). +- **Who is prompted**: MFA is required for users holding any role beyond **Reimbursement** and **Invoice approver**. A user whose access is limited to those two roles is not prompted for a second factor. +- **Remember this device**: Users can choose to be remembered, which suppresses the prompt on subsequent sign-ins for a limited period. - **Lost devices**: Recovery codes are not enabled. A user who loses their authenticator device needs an administrator to reset their MFA enrolment. ## Session Management @@ -177,9 +178,12 @@ Light's team will configure the connection on the Auth0 backend and test it with ### User Provisioning -SSO controls how users authenticate — it does not create their Light accounts. Users are **not** provisioned automatically on first sign-in, so each user must already exist in Light before they can sign in through SSO. +SSO controls how users authenticate — it does not create their Light accounts. Light does **not** support just-in-time (JIT) provisioning from your identity provider: users are not created on first sign-in, so each user must already exist in Light before they can sign in through SSO. A user who authenticates successfully at your identity provider but has no matching Light account will be denied access. -Create users in advance under **Business partners > Users**, using the same email address they will present from your identity provider. A user who authenticates successfully at your identity provider but has no matching Light account will be denied access. +Users can be created in either of two ways: + +- **Manually**, under **Business partners > Users**, using the same email address they will present from your identity provider. +- **Automatically from your HR system.** Light's HRM integration imports employees, keeps their active/inactive status in step, and assigns a default role — so joiners and leavers are handled without manual steps. See [HRM Integration (Finch)](/articles/11-integrations/11-8-hrm-finch). ### SAML Configuration