User session timeout not honored in EBOM management after password reset (tc-12.3)

PLM Teamcenter
, , , , , , , ,
1

We’ve discovered a concerning security issue in our Teamcenter 12.3 EBOM management module. After users reset their passwords through the standard password reset process, their existing sessions remain active indefinitely, completely ignoring the configured session timeout settings.

Our session timeout is set to 30 minutes of inactivity, and this works correctly under normal circumstances. However, when a user resets their password, we expect all their active sessions to be invalidated immediately. Instead, users can continue working in EBOM management for hours or even days without being forced to re-authenticate with their new password.

This creates a security risk - if someone gains unauthorized access to a workstation where a user previously logged in, they can continue accessing sensitive EBOM data even after the legitimate user has changed their password. The session timeout configuration appears correct in our web server settings. Is there a specific session invalidation policy we need to configure for password reset events in EBOM management?

2

This is likely a session persistence issue in your web server configuration. EBOM management might be using a different session store than other modules. Check if you’re using sticky sessions or session replication in your load balancer. When passwords are reset, the session invalidation signal might not be propagating to all session stores. Review your web.xml session-config settings.

3

Don’t forget about cached credentials in the Teamcenter rich client if you’re using that for EBOM management. The rich client sometimes caches authentication credentials locally and doesn’t check with the server on every operation. This could explain why sessions persist after password changes. Check the client configuration for credential caching settings and disable it if security is a priority.

4

The issue might be in how EBOM management handles session cookies. If the session cookie has a very long expiration time set, it won’t respect the server-side timeout. Look at the Set-Cookie headers when logging into EBOM management - check the Max-Age or Expires attributes. Also verify if the session cookie is being marked as HttpOnly and Secure to prevent client-side tampering.

5

From a security perspective, this is a critical vulnerability. Beyond just fixing the technical configuration, you should implement a policy that forces users to log out and back in after password resets. Also consider implementing concurrent session limits - if a user logs in from a new location after password reset, it should automatically terminate older sessions. Check if Teamcenter has a maximum concurrent sessions setting.

6

The session persistence after password reset in EBOM management is a configuration gap affecting all three critical areas. Here’s the comprehensive solution:

1. Session Invalidation Policy Configuration:

Teamcenter doesn’t automatically invalidate active sessions when passwords are reset - this must be explicitly configured. You need to enable forced session termination on credential changes:

Navigate to Teamcenter System Administration:

  • Go to Security > Session Management
  • Enable ‘Invalidate Active Sessions on Password Change’
  • Set ‘Session Invalidation Scope’ to ‘All User Sessions’ (not just ‘Current Session’)
  • Enable ‘Force Re-authentication After Credential Update’

For EBOM management specifically, there’s an additional module-level setting:

  • Open EBOM Management preferences
  • Under Security tab, enable ‘Strict Session Validation’
  • Set ‘Session Credential Check Frequency’ to ‘On Every Request’ (default is ‘On Session Start’)

This ensures EBOM validates the user’s current credentials on each operation, not just when the session begins.

2. Web Server Timeout Configuration Alignment:

The session timeout needs to be consistently configured across all layers. Your 30-minute timeout should be set in multiple places:

Application Server (Tomcat/WebLogic): Edit web.xml in your EBOM deployment:

<session-config>
  <session-timeout>30</session-timeout>
  <cookie-config>
    <max-age>1800</max-age>
    <http-only>true</http-only>
    <secure>true</secure>
  </cookie-config>
</session-config>

Teamcenter Preference:

  • Organization > Preferences > Session
  • Set ‘Session Timeout’ to 30 minutes
  • Enable ‘Enforce Timeout on Idle Only’ (not on active sessions)
  • Set ‘Session Timeout Warning’ to 5 minutes (warns users before timeout)

Load Balancer/Reverse Proxy: If using a load balancer, ensure session affinity timeout matches:

  • Set sticky session timeout to 30 minutes
  • Enable session draining on password reset events
  • Configure health check to validate session state

The key issue is when these timeouts don’t align - the longest one effectively becomes the actual timeout.

3. Password Reset Handling Implementation:

Implement a custom event handler that triggers on password reset events. This handler should:

  1. Identify all active sessions for the user whose password changed
  2. Invalidate those sessions in the session store
  3. Send session termination signals to all connected clients
  4. Log the invalidation for security audit purposes

Create a Java event handler class that listens for password change events:

// Pseudocode - Key implementation steps:
1. Register listener for UserCredentialChangeEvent
2. On event trigger, query SessionManager for user's active sessions
3. Iterate through sessions and call session.invalidate() for each
4. Clear any cached credentials from Redis/session store
5. Broadcast logout message to connected EBOM clients
6. Log security event with user ID, timestamp, session IDs
// See documentation: Teamcenter Event Handler Guide Section 7.3

Register this handler in Teamcenter:

  • Go to Business Modeler IDE
  • Create new Event Handler
  • Attach to ‘User Credential Change’ event
  • Deploy to all method servers

Additional Security Hardening:

Implement Concurrent Session Limits:

  • Set maximum concurrent sessions per user to 2
  • When limit exceeded, terminate oldest session automatically
  • Configure in Organization preferences under Session Management

Enable Session Activity Monitoring:

  • Track IP address and user agent for each session
  • If these change mid-session, require re-authentication
  • Detects session hijacking attempts

Configure Forced Logout on Suspicious Activity:

  • Multiple failed authentication attempts
  • Access from new geographic location
  • Unusual EBOM data access patterns

Immediate Remediation Steps:

  1. Identify all currently active sessions: Query the session table in Teamcenter database
  2. For users who recently reset passwords, manually invalidate their sessions
  3. Force all EBOM users to log out and back in after implementing configuration changes
  4. Monitor session logs for the next 48 hours to verify proper timeout behavior
  5. Conduct security audit to check if unauthorized access occurred during the vulnerability window

Testing and Verification:

After implementing these changes:

  1. Have a test user log into EBOM management
  2. Note their session ID from the logs
  3. Reset the test user’s password through the standard process
  4. Verify the original session is immediately invalidated (check session table)
  5. Confirm the user cannot perform any EBOM operations with the old session
  6. Verify session timeout triggers at exactly 30 minutes of inactivity
  7. Test that warning appears 5 minutes before timeout

This comprehensive approach addresses the session invalidation policy gap, aligns timeout configurations across all layers, and implements proper password reset handling to eliminate the security risk in EBOM management.

7

I’ve seen this behavior before. The problem is that password reset typically only invalidates authentication tokens, not the application session itself. The EBOM module maintains its own session state separate from the authentication layer. You need to configure a session invalidation hook that triggers when password changes occur. Look for event handlers or listeners that can be configured to force logout on password reset events.