You may want to first read about the difference between a session and a cookie.

Application server level vs. Application level vs. Web container level

First and foremost, it is important to recognize that by default, sessions are managed at the application server level, at Server > Server Types > Websphere applications servers > your application server > Session management. By default, session management options at the application level are greyed out, at Application > Application Types > Websphere enterprise applications > your application > Session management. You can override session management so that the session management options at the application level takes precedence.

There is also an option to configure sessions at Server > Server Types > Websphere applications servers > your application server > Web container settings > Web container > Session management. Making a change in the web container is exactly the same as making a change at Server > Server Types > Websphere applications servers > your application server > Session management. To learn more about Web Containers, refer to our web container getting started article.

Session ID

A session ID is created when a WebSphere application is opened in a web browser and by default, the session is destroyed when the web browser is closed (this can be changed). WebSphere has 3 session tracking mechanisms. By default, only Enable cookies is enabled. 

When enable cookies is selected, a cookie will be created on the client PC when requesting the app running on WebSphere. By default, the cookie is named JSESSIONID. In this example, the session ID is 0000a12dvSZHLFhx0hIWFJYVC_-:-1).

• Enable cookies will take precedence over Enable URL rewriting. When Enable cookies is checked, the session ID will attempt to be obtained from a cookie.
• Enable SSL ID tracking will take precedence over Enable cookies and Enable URL rewriting. When Enable SSL ID tracking is enabled, the session ID will attempt to be obtained from SSL information.
• ​Enable URL rewriting - When Enable URL rewriting is enabled, the session ID will attempt to be obtained from the URL. If Enable protocol switch rewriting is enabled, the session ID will attempt to be retained when switching from HTTP to HTTPS, and vice versa.

Session Affinity / Workload Management (WLM)

Sessions provide affinity, so that requests from a certain browser are routed to a certain application server. Workload Management (WLM) is the brains behind affinity. 

Concurrent (simultaneous) sessions

By default, concurrent sessions are disabled, which means that users are not allowed to have two or more simultaneous sessions. However, you can enable concurrent session and you can also limit the number of concurrent sessions a user can have.

Maximum sessions limit

By default, when a new application server is created, sessions are managed at the application server level, a maximum of 1000 sessions are allowed per application server, and allow overflow is enabled, and excessive sessions are not stored in a database or in memory. This configuration could cause an application server to run out of memory and heap dump. Refer to this article for more details on this, including tuning recommendations.

Deny access to unsecured (HTTP) content

By default, access to unsecured content (HTTP) is allowed. Security integration can be used to deny access to unsecured content.

Distributed environment settings

Distrubuted sessions is the idea of distributing sessions across two or more application servers or applications in a cluster.