This is some text to make the heading work.
In the remainder of this article, the
following terms will be used without further explanations:
This is some text to make the heading work.
The unauthenticated mode is the default
mode when enabling remember me cookie with or without step-up
authentication, corresponding to the setting
j2eeAuthenticate set to
false in the
WP RememberMeConfigService resource environment provider
(see e.g.
Configuring Remember me for J2EE authentication on Linux
). It means that
even when providing a valid remember me cookie, a user is still
treated as unauthenticated in terms of Portal Access Control. So the
user identified by the remember me cookie will only see the page
navigation for public pages (like the anonymous user), and will be
prompted to authenticate by user id and password when trying to
access a protected page. However, portlets or the Portal theme on
public pages can make use of the Portal User Management API (PUMA) to
display personalized information based on the user identity provided
by the remember me cookie. In particular, the
com.ibm.portal.um.PumaProfile.getCurrentUser() method of this API
returns the user according to the remember me cookie id when being
called from an unauthenticated context. Note that it is not possible
to personalize the Portal user experience based on visibility rules
for pages or portlets in this case, since attribute based
administration is only available to authenticated users (see
Attribute Based Administration).
Additionally, the login and the
remember me cookie portlet services provide an interface to handle
remember me cookies (with operations like getting the cookie user id
as a string or generating a URL the user can click to invalidate the
cookie). See this developerWorks article for more details on those two portlet services.
The unauthenticated mode of the
remember me cookie does not require step-up authentication to be
enabled. In fact, unless you have the necessity to provide additional
authentication levels than the default ones (standard, identified,
authenticated), enabling step-up authentication for this scenario
only makes sense if you want to enforce the presence of the remember
me cookie for particular public pages or portlets. In that case, you
would additionally protect a page or portlet that is available to the
anonymous user by the identified step-up authentication level. This
would not change the Portal navigation in any way, but ensure that
only users with a valid remember me cookie can access the respective
page or a page that contains an instance of the respective portlet,
and enforce a login with user id and password to
deliver a remember me cookie otherwise.
The unauthenticated mode configuration is suited for
scenarios where it is sufficient to handle personalized information
for cookie identified users in the theme or in portlets, like e.g.
greeting the user by name and displaying personalized recommendations
or dashboard information. Every other operation that involves the
user identity (like personalized page/portlet preferences, user
specific WCM content except for the user
name component that is aware of cookie identified users),
private credential vault slots, user specific roles or permissions
etc.) does require a full login by user name and password.
The following table gives an overview
of the behavior of the main use cases when remember me cookie is
configured for j2eeAuthenticate=false,
and step-up authentication is disabled.
The cookie-based
login
only occurs when a protected Portal
page is accessed. When accessing a public Portal page with a valid
remember me cookie, the behavior is not different from the one
described in the previous section for the unauthenticated mode. So
Portal still displays the navigation for the anonymous user and
allows limited personalization inside the theme and portlets through
the PUMA. Running a scenario where users presenting a remember me
cookie are always automatically logged in requires additional steps.
Currently, there are two solutions for this:
- Perform a redirect to the
protected area if a public page that has the authentication level
identified is accessed and a valid remember me cookie is presented.
This makes sure that at least for all pages protected with the
identified level, an automatic login based on the remember me cookie
occurs. If no remember me cookie is present, the user is challenged
for a full login by user id and password. To achieve this behavior,
add or modify the following properties in the WP StepUpConfigService
resource environment provider:
- name:
sua.authLevel.identified.authLevelVerifier
type: String
value:
com.ibm.wps.auth.sua.impl.AuthLevelVerifierRememberMeJ2EEb) - name: sua.authLevel.identified.stepUpAuthHandler
type:
String
value:
com.ibm.wps.auth.sua.impl.StepUpAuthHandlerRememberMeJ2EEc) - name: sua.authLevel.identified.postRedirectionTargetProtected
type:
Boolean
value: true
The settings require a server/cluster
restart to become effective. - Always trigger a redirect to the
according protected page if a public page is accessed and a remember
me cookie is presented, independently of the authentication level
set on the page. This requires a customized component that is
described in a |separate wiki article in more detail.
In general, logging in the user
automatically based on the cookie may lead to a very high number of
logins in large scale scenarios, which should be reflected in the
performance and capacity planning.Single Sign-On Scenarios
The Portal triggers a full login for
the cookie user, leading to a full WebSphere security context to be
created. After that, only a WebSphere Portal server with the same
step-up authentication configuration will properly enforce a second
login with user id and password
(or another custom authentication level) if this is necessary. All
other components in the same Single-Sign On (SSO) domain will by
default not understand what proof of identity was used to establish
the security context and treat the user as fully authenticated.
However, the information about the authentication method is available
in the security subject, and can be evaluated by other components in
the same SSO domain. The current authentication method is stored as
an additional attribute com.ibm.wsspi.sec.cred.authMethod
to the LTPA token 2 ssoToken in the private credentials of the
security subject. Possible values are „identified“ for the
remember me cookie authentication, and „basic“ for the user
id and password authentication. An appendix at the end of
the article provides a code snippet that shows how a custom login
module or code in an application could read the authentication level
from the WebSphere security subject in order to use it for additional
enforcement checks.
Logout - „Forget Me“
In all of the described scenarios and
configuration alternatives, WebSphere Portal does not invalidate the
remember me cookie upon logout. This behavior is intended, but
requires attention in the case of the authenticated mode, especially
if one of the solutions for automatic login based on the cookie is
configured. Depending on the overall scenario, it might be necessary
to add custom logic to invalidate the remember me cookie upon logout
to prevent that the user is logged back in immediately by presenting
a remember me cookie. An example that achieves this by employing a
custom logout filter is also contained in the previously mentioned
wiki article.
Implications on Administration
By default, pages and portlets have the
authentication level standard. The actual value of this level depends
on the resource's access control settings. Protected resources that
are not accessible to the anonymous user get the level authenticated,
meaning that those resources require a full login
by user id and password. So additional administrative steps in the
Portal may be necessary to make sure those resources that are
intended to be accessible after a cookie-based login without another
authentication challenge are protected with the identified or a lower
authentication level.
Also note that
using attribute based administration (i.e. visibility rules for pages
and portlets) adds a third dimension for controlling access in
addition to access control and step-up authentication. In general, it
is recommended thoroughly check whether any of the two additional
dimensions step-up authentication and visibility rules can be avoided
in a particular scenario, since each adds another layer of
administrative complexity to the solution.
Scenarios
Overall, the authenticated mode
configuration for the remember me cookie is suited for scenarios
where the identity from the remember me cookie already counts as a
means of authentication that allows users to see and use their
individual personalized Portal page structure and preferences.
Particular pages and portlets can additionally be protected by other
authentication methods (by default user id
and password) using the step-up authentication framework.
Detailed Use Case Behavior
The following table gives an overview
of the different use cases and the resulting behavior for the
j2eeAuthenticate
=true and step-up authentication enabled setup.
Note that in this case the combination protected page+authentication
level identified is viable, since this is exactly the case where an
automatic login occurs if a valid remember me cookie is presented.
* With additional configuration
settings / customizations described in a previous section, this case
can be modified in a way that an automatic redirect to the protected
Portal area is triggered.
Summary and Recommendations
This article highlighted the different
configuration modes for the remember me cookie functionality in
Portal, and the dependency of this feature to access control and
step-up authentication. Overall, when planning to use the remember me
cookie functionality, the easiest and most straight-forward way is to
use the default unauthenticated mode without enabling step-up
authentication. With that configuration, portlets and/or the theme
must be implemented in a way that they handle cookie-based
personalization properly by using PUMA when running on public pages,
displaying general information for the anonymous user if no remember
me cookie is present, and personalized information for the cookie
user if a valid cookie is provided. This is both recommended for
performance reasons (saving the potentially high number of logins
based on the cookie), and security reasons (avoiding the SSO impact
of creating a full security context for users that are only
identified by cookie). Only if the performance and security
implications are well understood and mitigated, it is viable to use
the authenticated mode for providing a deep personalization
experience for users based on the remember me cookie.
==Appendix Reading the
authentication level from the security subject==
The following code snippet shows how to
read the authentication method from the WebSphere subject as it is
present after a login triggered by WebSphere Portal with the step-up
authentication feature enabled. The code can be run in any WebSphere
application or custom component (like a JAAS login module). Possible
values returned can be „basic“ (for user
id/password authentication) and „identified“ (for
remember me cookie based authentication).
{code:||600|600}
import java.util.Iterator;
import java.util.Set;
import
com.ibm.websphere.security.WSSecurityException;
import javax.security.auth.Subject;
import
com.ibm.websphere.security.auth.WSSubject;
import
com.ibm.wsspi.security.token.SingleSignonToken;
protected String
getAuthLevelFromLTPAToken2() throws WSSecurityException {
String authLevel = null;
Subject subject =
WSSubject.getRunAsSubject();
if (subject != null) {
// get all single sign-on tokens and
select the LTPA token 2
Set ssoTokens =
subject.getPrivateCredentials(SingleSignonToken.class);
if (ssoTokens != null) {
for (Iterator iter =
ssoTokens.iterator(); iter.hasNext();) {
SingleSignonToken ssoToken =
(SingleSignonToken) iter.next();
// check whether it is the LTPA token
2
if
("LtpaToken".equals(ssoToken.getName()) &&
ssoToken.getVersion() == 2) {
// obtain the auth method from the
ltpa token 2
String[] authMethods =
ssoToken.getAttributes(TOKEN_ATTR_AUTH_METHOD);
if (authMethods != null &&
authMethods.length > 0) {
authLevel = authMethods[0];
}
}
}
}
return authLevel;
}
{code}