IBM BS029ML - WebSphere Portal Server Self Help Manual page 106

registry configured in WebSphere Application Server, and then, if this authentication
succeeds, creates the LTPA cookie. Taking the stackable feature of the JAAS model, the
Portal_LTPA JAAS configuration can also be extended by custom login modules, such that
administrators and developers can incorporate additional checks specific to their
environments.
The result of the login is an object of javax.security.auth.Subject, representing a grouping of
related information for a single entity, such as a person. It contains identities (represented as
a javax.security.Principal object), and security-related attributes (such as passwords or
cryptographic keys) as credentials. This "WebSphere Application Server subject" forms the
security context associated with the authenticated user and can be used by the Application
Server login to pass the context to the WebSphere Portal Login. WebSphere Portal then can
retrieve the Application Server user identity to perform additional portal related login steps.
WebSphere Portal Login first creates the "Portal subject", which is represented by a
javax.security.auth.Subject object. This second subject represents the same unique security
name and LTPA token as the WebSphere Application Server subject and is populated with the
same principals and public credentials. The difference in this Portal subject is that, unlike the
WebSphere Application Server subject, it is not locked down after the successful
authentication; it can be modified later on by any portlet using the Credential Vault portlet
service. Another difference is that the Portal subject is not shared with applications besides
WebSphere Portal.
The Portal subject is also passed on to the optional Portal JAAS login. Depending on the
configuration, WebSphere Portal triggers a second JAAS login called Portal_Login, which you
can extend using custom login modules.
WebSphere Portal Login also creates the session unless the session has already been
created for the anonymous user (when "public.session" is set to true in portal ConfigService),
or there is no need for a Web Container session (if the XMLaccess command interface or the
portal scripting interface triggered the login process). Finally, the portal user object is returned
to the calling code.
There are many ways to trigger the user login process. They are summarized in Table 4-1.
Table 4-1 Login access points
Login point
Normal portal login using the Login
Portlet or Login Screen.
Direct access to a protected URL.
Portal direct login URL.
XMLaccess command-line
interface
Portal Scripting Interface
92
IBM WebSphere Portal V6 Self Help Guide
The flow
Triggers the engine command LoginUser, which essentially
triggers the Login process described in this section.
The application server redirects to a redirect form, which
invokes a special servlet filter for detecting virtual portal login,
and then redirects to the virtual portal login form.
The Portal login URL directly executes LoginUser engine
command through the encoded URL.
The XMLaccess servlet called by the client directly triggers the
application server login using the user credentials taken from
the command arguments. When XMLaccess is triggered within
the Portal administration GUI, the security context is the current
user credentials.
Triggers the WebSphere Application Server and Portal Login by
the Portal Scripting MBean. The user credentials are taken from
the $Login scripting command.