Influitive SSO: Why Former Users May Retain Hub Access and How to Enforce Session Timeouts

Solution

Issue

Former users may still be able to access parts of an Influitive hub for an extended period after being disabled in your SSO IdP because they are not being forced to re-authenticate.

Reported symptom (verbatim)

• “Former clients are able to access the hub months after their SSO access has been disabled… it’s as if their cookies never expired.”

No specific on-screen error text is required to identify this behavior. The expected behavior is that once the user is forced through SSO again, authentication should fail at the IdP and the user should not regain access.

Key concept: Influitive “session timeout” vs. SSO (IdP) session lifetime

1) Influitive Discussions-only timeout

Influitive has a “session timeout” configuration for the Discussions area only:

• Affects: https://your_instance.domain.com/forum/
• Does not affect: other areas of the Influitive instance outside /forum/

You can review this setting here:

• https://your_instance.domain.com/forum/admin/site_settings/category/login

This setting is useful for expiring sessions in Discussions, but it will not, by itself, ensure that users must re-authenticate via SSO to access the rest of the hub.

2) SSO session enforcement must be done at your IdP

If you use SSO, the effective “how long can someone stay signed in” behavior for the overall hub experience must be enforced by your Identity Provider (IdP) (for example, https://your_idp.domain.com).

Influitive honors whatever session timeout rules your IdP applies to the Influitive application (idle timeout, maximum session lifetime, re-authentication requirements, etc.).

Resolution / Mitigation (SSO environments)

Step 1 — Confirm offboarding state (diagnostic)

For any impacted user, determine:

• Is the user disabled in the IdP only?
• Is the user also locked/deactivated in Influitive?

If the Influitive account remains active, the user may continue accessing the hub until they are forced to re-authenticate through SSO (depending on IdP/session behavior).

Step 2 — Enforce session timeout in your IdP (primary control)

In your IdP configuration for the Influitive SSO application:

1. Set an appropriate idle session timeout (forces re-authentication after inactivity).
2. Set an appropriate maximum session lifetime (forces re-authentication even if the user remains active).
3. Ensure the policy applies to the Influitive application and the user populations that access it.

This is the control that prevents “months-long” access because it forces periodic re-authentication; once re-authentication is required, SSO-disabled users cannot authenticate.

Step 3 — Lock/deactivate Influitive users during offboarding (recommended)

To immediately remove access when a customer is termed or a user should no longer have access:

1. Lock or deactivate the user in Influitive as part of your offboarding process (manual or automated).
2. Keep IdP disabling in place as a second layer of enforcement.

This ensures that even if the IdP session were still valid on a device, the user’s Influitive account status also prevents continued access once re-authentication occurs.

Important behavior boundary: No engineering fix is required for this scenario. This is expected product behavior based on configuration scope (Discussions-only timeout vs. full-instance SSO session control).

Validation

1. In a test environment (or with a test user), sign in via SSO and access:
   • Discussions (/forum/)
   • A non-Discussions area of the hub (any page outside /forum/)
2. Wait beyond the IdP session timeout you configured (idle and/or maximum lifetime).
3. Verify the user is forced to re-authenticate via SSO.
4. Disable the test user in the IdP (and/or lock in Influitive), then repeat the prior step:
   • Confirm re-authentication fails and the user cannot regain access.

If users are still not being forced to re-authenticate after the IdP timeout, review IdP policy assignment, application session settings, and whether the IdP is actually enforcing timeouts for that specific application.