J2EE, Enterprise Portal, and the application server have overlapping security models. By integrating the security functionality of these models, PortalSession authentication provides:
Access to server components, subject to user roles, once the user has been authenticated by the server.
High-availability access (failover) to other configured servers without requiring that the user log in to the new server.
Stronger security against intrusion from clients who have not been authenticated by the portal.
Once the integration of the three security models is implemented, visitors to the secured system can access any component for which their user roles permit. All requests to applications that are hosted on the server are intercepted by the server, which performs access permission checks. If the user has the appropriate role, the request is processed; otherwise, an error is returned and the request is denied.
Further, when the user successfully logs in to the system, the PortalSession object persists so the user does not have to reenter login information when accessing other Web-based applications that are part of the secured system.
For EAServer, you can extend and maintain the authenticated session beyond the lifetime enforced by the server by using the methods CtsSecurity::SessionInfo::setName and CtsSecurity::AuthService::getCallerPrincipal. If these methods are implemented, then you must also handle the user authorization by implementing either a role service or authorization service. The internal role-checking performed by EAServer does not work unless you add the alternate user name to the authorized user’s list for the role. Since the alternate user name that is set using the setName API can be dynamic, the role service or authorization service should work in tandem with the authentication service to authorize the user.
