The logout can be initiated by a URI that is explicitly selected when the user clicks on the logout button (which has been added by the aggregation engine to every page banner). Alternatively, the logout can be initiated implicitly through a session timeout that occurs after a specified time of inactivity.
The portal logout performs the following actions:
1. Suspend User Session. The user’s portal session (the portal’s navigational state) is persisted. The HTTP session is invalidated.
2. Portlet user logout. The portlets are notified of the event user logged out to give them the opportunity to finalize (trans-)actions that need to be terminated.
The following steps are performed only when the logout is initiated by an explicit user action. They are not performed when the logout is a consequence of a timeout.
3. WebSphere Application Server logout. The user’s credential token is marked as invalid, and a respective cookie invalidation command is added to the response.
4. Browser redirect (302). The browser is redirected to render the post-logout target.
HTTP Basic Authentication has the following known disadvantage. The browser caches the user ID and password and sends them with every request to the same target. Because there is no standardized mechanism through which the browser is notified of a user-initiated logout, the browser continues to implicitly log in the user, as soon as the same target is accessed again.
In the case of an authentication proxy, WebSphere Portal needs to be set up to redirect after logout to the authentication proxy’s logout page. This way the authentication proxy is also notified of the logout. If a user does not logout explicitly, the proxy cannot be notified of the portal session timeout and the proxy session will time out eventually as well.
Filed in: WPS
How does the portal logout work if you have custom interceptor? how would you set the various timeouts such as ltpa, security caching, http session,etc..
Post a Comment