User manual | Leveraging WebSphere Portal V6 programming model, Part 4:

Leveraging WebSphere Portal V6 programming model, Part 4:

Understanding and configuring WebSphere Portal login and logout

Dr. Dieter Buehler

, WebSphere Portal Security Architect, IBM

Thomas Hurek

, WebSphere Portal L3 Lead, IBM

13 June 2007

Abstract

Earlier articles in this

series

covered various patterns for linking together different components in your portal to address business requirements. In this part, you learn more about one of the basic infrastructure services that IBM® WebSphere® Portal Version 6 provides--that is, the mechanism which enables users to login and logout of a portal, and how to configure and customize the login and logout behavior.

The flow of authenticating a user, maintaining the user's session, and logging the user off again belongs to the basic usage patterns of Web-based systems and plays a major role in Web security. Although the basic flow is always the same, many systems require adapting or enhancing for special purposes. Using a portal running under WebSphere Portal as your unified

Web front-end, you can rely on a complex and rich authentication component that you can configure and customize in various ways. This article provides an in-depth description of the

WebSphere Portal V6 login and logout behavior and various configuration and customization options. (The content described here also applies to WebSphere Portal versions 5.1.0.x.)

Table of contents

Introduction.................................................................................................................................. 2

Understanding WebSphere Portal login and logout..................................................................... 2

Default login configuration and possible authentication mechanisms .................................... 2

WebSphere Application Server login and WebSphere Portal login .................................... 4

Login using the login portlet................................................................................................ 5

Directly accessing a protected portal page........................................................................... 5

Login for the Scripting Interface.......................................................................................... 7

Login authenticated by Application Server ............................................................................. 7

Logout and session timeout ..................................................................................................... 9

Portal logout......................................................................................................................... 9

Session timeout .................................................................................................................. 10

Configuration options ................................................................................................................ 10

Changing the authentication method for the portal Web application .................................... 10

Enabling WebSphere Portal JAAS login ............................................................................... 12

Switching to screen login....................................................................................................... 12

Reducing database traffic during login .................................................................................. 12

Redirect after login or logout................................................................................................. 13

Influencing logout behavior................................................................................................... 15

Disabling particular login entry points .................................................................................. 16

Conclusion ................................................................................................................................. 16

Resources ................................................................................................................................... 16

About the authors....................................................................................................................... 17

Introduction

The article consists of two parts. The first part provides a general explanation of different cases and scenarios about login and logout in WebSphere Portal; configuration and customization options are only mentioned to clarify their context. In the second part, particular configuration options or their combinations are covered in detail.

Understanding WebSphere Portal login and logout

To gain a sound basis for deciding how to customize the portal login or logout flow, you first need a basic understanding of what happens when a login or logout in WebSphere Portal is performed. You also need to understand the configuration options that exist for controlling

Portal login and logout and the available plug points for custom code that you can leverage if the configuration options do not meet all your specific business requirements. This section provides this foundation.

Default login configuration and possible authentication mechanisms

Because WebSphere Portal is a J2EE application running on WebSphere Application Server

(Application Server), it can leverage the authentication mechanisms offered by the underlying

Application Server security infrastructure. By default, the configuration is set to form-based login using a custom login form provided by the login portlet (beginning with Version 5.1.0) or the login screen (for older versions; newer versions can optionally be switched back). This

form-based login can be triggered either directly or by intercepting the Application Server when a protected URL is addressed without prior authentication.

Besides that, WebSphere Portal also supports the following configurations:

• SSL client certificate authentication only. You can configure the portal to use SSL mutual authentication to identify the user. In this configuration, the Application Server triggers the appropriate SSL handshake and requests the client certificate if a protected URL is addressed without a security context. The client then has to provide a valid certificate that can be validated against a certificate that is contained in the associated SSL trust store on the server. If the handshake succeeds, the client is logged in with the user identity from the client certificate. You can configure the mapping of client certificate identities to users on the server in Application Server.

• SSL client certificate authentication and form-based login. You can have scenarios in which WebSphere Portal is configured for client certificate authentication, and also trigger a form-based login using the login portlet or screen. Depending on the detailed configuration, this hybrid approach can be either used for double authentication (user id/password and client certificate at the same time), or for supporting both methods alternatively.

Although it is possible to configure the WebSphere Portal Web application for HTTP Basic

Authentication only, this configuration is neither supported nor recommended. However, as of

Version 6.0.1, WebSphere Portal provides a facility called Basic Authentication Trust

Association Interceptor that lets you use basic authentication for particular clients or entry

URLs in addition to any of the above authentication mechanisms. The facility must be enabled and can be configured based on whitelist and blacklist expressions for the user agent and

URL. See the

Enabling HTTP Basic Authentication for simple clients

topic in the WebSphere

Portal Information Center for a detailed description. For some levels of WebSphere

Application Server, you might need to apply PK34390 to use this feature successfully.

Figure 1. Login using the default WebSphere Portal mechanism

Figure 1 summarizes the WebSphere Portal login flow as it occurs by default for the direct entry points to WebSphere Portal (the login portlet, the login URL, the XML Configuration

Interface, and the Scripting Interface). This mechanism is based on user id/password authentication. The green arrows in the diagram show where the user id/password information flows. This mechanism always works regardless of the authentication method that is defined for WebSphere Portal or external security components. Therefore, if you want to prevent users from logging in through one or more of those entry points, you must take appropriate steps to disable or ignore these. You learn more details about how to disable these entry points later in this article.

Next, let's look at the general part shared by all entry points, namely the WebSphere

Application Server Login and WebSphere Portal Login. Then, you learn about the individual entry points and their specific aspects in more detail.

WebSphere Application Server login and WebSphere Portal login

For authentication, WebSphere Portal code triggers a programmatic JAAS login [1] using a

JAAS configuration in WebSphere Application Server called

Portal_LTPA

. This JAAS login module stack performs the authentication against the user repository that is configured in

Application Server and, if this authentication succeeds, establishes the LTPA token. The

WebSphere Portal_LTPA JAAS configuration can also be extended by custom login modules

(see [2] for details).

The result of this login is a javax.security.auth.Subject

object, which represents a grouping of related information for a single entity such as a person. It contains identities

(represented as javax.security.Principal

objects), and security-related attributes (such as passwords or cryptographic keys) represented by private and public credentials. This "WAS 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. Then,

WebSphere Portal can retrieve the Application Server user identity to perform the 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 WAS subject and is populated with the same principals and public credentials. The difference in this Portal subject is that, unlike the WAS subject, it is not locked down after successful authentication; it can be modified later on by any portlet using

the Credential Vault portlet service (see [3] for details about the API for the Credential Vault

service). Another difference is that the Portal subject is not shared with applications besides

WebSphere Portal. Both differences can be advantageous or disadvantageous depending on the specific scenario.

The Portal subject is also passed on to the optional Portal JAAS login. Depending on the configuration, WebSphere Portal triggers a second JAAS login

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 (which will be the case if you enabled the public session feature in

WebSphere Portal), or there is no need for a Web container session (in the case in which the login is triggered by the XML configuration or the scripting interface). Finally, the Portal user object, according to the distinguished name in the subject, is loaded and returned to the calling code.

Login using the login portlet

You can use the login portlet shipped with WebSphere Portal to trigger a form-based login from any public portal page, that is, a page which is accessible to the anonymous portal user.

By default, the login portlet is placed on the "Welcome" page that is displayed as the starting page of WebSphere Portal (beginning with V6.0), and on the "Login" page that is displayed when the user clicks the Login link in the portal navigation. Because you can restrict virtual portals to particular user realms to configure disjoint sets of users per virtual portal, there are distinct copies of these pages for each virtual portal. So, the corresponding login is performed in the scope of the user realm associated with the respective virtual portal.

As shown in

Figure 1

, submitting the login form on the login portlet executes the

LoginUser command, which triggers the Application Server login and Portal login described in the previous section. If the authentication fails for some reason, the

LoginUser

command passes the exception to the login portlet which shows a corresponding error message. If the authentication succeeds, the

LoginUser

command triggers a redirect that depends on the situation and on several configuration settings (described later).

Directly accessing a protected portal page

When the portal is configured for form-based authentication and the user directly addresses a

URL in the protected portal area without prior authentication (for example, by following a

bookmarked or copied link), the flow is a bit different, as shown in Figure . In this case, the

Application Server detects that there is no security context yet and sends a redirect to the form-

Changing the authentication method for the portal Web application

). This form-login page routes the request

to a special servlet filter that determines the virtual portal that is addressed by the URL, and redirects again to the corresponding login page (remember there is a separate login page for

each virtual portal). After that, the flow is the same as described in the previous section except for the redirect after a successful login which targets, by default, to the protected URL that has been originally addressed.

Figure 2: Flow for directly accessing a protected portal page

Login using the WebSphere Portal login URL

To trigger a WebSphere Portal login without requiring the user to enter the user id and password in a form and submit it (for example, for automated tasks performed by agents or rich clients, or simply for convenience), WebSphere Portal provides a facility called a login

URL. The URL, shown below, encodes the information to trigger the

LoginUser

command as shown in

Figure 1

<server>:<port>/wps/portal/cxml/04_SD9ePMtCP1I800I_KydQvyHFUBADPmuQy

The URL can be used with both HTTP and HTTPS and for both GET and POST requests.

Using a GET request to log into WebSphere Portal is not recommended, in this case, because the login credentials (user name and password) are typically logged in clear text by the HTTP server and the browser history. The following request parameters are supported: userid password

WPSRedirectURL selectionID yes yes

The user id of the user that should be logged in.

The password of the user.

The URL Portal should redirect to after a successful login

The unique name of a page Portal should redirect to after a successful login

If the login is successful, the caller receives an HTTP

302

response and a redirect. If the login fails for any reason, the caller receives an HTTP error code starting with

4xx

Listing 1 shows a simple usage example for the login URL as an HTML form login page.

Listing 1. Example HTML form using the login URL

<html>

<body>

<h2>Login URL POST test page </h2>

<form action="<your host>:<your port>/wps/portal/cxml/04_SD9ePMtCP1I800I_KydQvyHFUBADPmuQy" method="POST"/>

User ID: <input type="text" name="userid"/> <br>

Password: <input type="password" name="password"/><br>

</form>

</body>

</html>

Login for the XML configuration interface

The XML configuration interface is a separate servlet in the WebSphere Portal J2EE enterprise application that is called by the XML configuration command line client. This servlet gets the user id and password information from the request and uses it to directly trigger the

Application Server login and WebSphere Portal login as illustrated in

Figure 1

. This step is done again for each XML configuration request. If the authentication fails, the servlet returns an appropriate error description. If the login succeeds, the servlet continues to process the

XML configuration request.

This type of authentication only applies to the XML configuration command line client. You can also trigger XML import or export operations from several points in the administrative portlets in the WebSphere Portal UI. For this latter use case, WebSphere Portal takes the security context of the current portal user.

Login for the Scripting Interface

The Scripting Interface triggers the Application Server login and WebSphere Portal login from the implementation of the Portal Scripting

MBean

. It uses the user id and password passed as arguments to the

$login

scripting command. If these arguments are omitted, the user identity that helped establish the connection when invoking the Portal scripting client is picked up from

Application Server and reused for the WebSphere Portal login (see the next section Login

authenticated by Server). The scripting client then takes this user identity to create a scripting

session for this user.

Login authenticated by Application Server

The actual authentication is not always triggered from within WebSphere Portal. There are cases where a valid Application Server security context has already been associated with a portal request outside of WebSphere Portal. This can be the case if any of the following are true:

• The authentication was performed by another server in the WebSphere Single Sign-on

(SSO) domain.

• The authentication was performed for another secured application on the same server.

• The authentication was performed by a dedicated external security manager that is integrated with Application Server security runtime using the Trust Association Interceptor

(TAI) plug-point.

• WebSphere Portal is configured for client certificate authentication.

• The Portal scripting interface with Application Server authentication is used to access the portal.

The flow for these cases differs from that for direct WebSphere Portal login as shown in Figure

Figure 3: Login being authenticated by Application Server

Except for the scripting client case, the Application Server authentication is triggered by accessing a protected URL directly. Before the Web container in the Application Server passes such a request on to the portal application, it makes sure that it is authenticated by checking if there is a valid LTPA cookie coming with the request. The Application Server will also accept

LTPA cookies created by other applications or servers in the same Single Sign-on domain.

If there is no LTPA cookie, Application Server tries to authenticate the request. The security run time first checks for a TAI that can authenticate the current request. If so, the particular

TAI implementation will either reject the authentication or assert the user identity to the

Application Server (for details on the TAI mechanism see [4] and [5]). If there is no TAI

available, or none can handle the request, the Application Server runtime applies the authentication method specified in the corresponding security configuration of the portal Web application, for example, the SSL handshake for client certificate authentication.

Regardless of how the authentication actually happens, if it succeeds, WebSphere will associate a corresponding security context to the request and pass it on to the WebSphere

Portal servlet.

In this scenario, when WebSphere Portal detects that a protected page is accessed and

WebSphere Portal login has not yet happened, it executes the

LoginUser

command. This

triggers the same flow as for the default WebSphere Portal login mechanism (see

Figure 1

however the Application Server login is now much simpler, because the user identity can be directly picked up from the existing Application Server security context. The WebSphere

Portal login is the same as for the default WebSphere Portal login flow.

When using the scripting client with Application Server authentication, the Application Server security context is built during the creation of the scripting client connection when the

Application Server user and password are passed in as arguments (that is, when calling the wpscript.sh -port 1234 -user wsadmin -password ***

command on the command line).

Logout and session timeout

Portal logout

The portal logout is the flow triggered by WebSphere Portal to log off the user. It is performed on several occasions:

• Explicit logout when the user clicks the "logout" link when navigating the protected portal area.

• An authenticated user accesses a public portal page.

• A user whose session has timed out before the Application Server security context timed out navigates directly to a protected portal page.

• A user tries to access a page that belongs to a virtual portal associated with a user realm that does not include that user as a member.

Some of these occasions can be influenced by particular properties described in the next chapter.

Figure 4: Overview of the portal logout flow

Figure 4 shows the basic flow when a portal logout is triggered. Similar to login, the logout is implemented as a command, in this case called

LogoutUser

. If security is enabled, the command first revokes all Application Server security tokens, implying that the user will be logged off from WebSphere Portal as well as from all other applications in the same Single

Sign-on domain that rely on the Application Server security context. Then, it triggers the invalidation of all portlet sessions. Furthermore, the command logs the user off of Web

Content Management by doing an include

on the Web Content Management logout JSP. (You can optionally switch off the previous step if your environment does not use Web Content

Management). Finally, the logout command invalidates the portal session and performs a redirect to the appropriate post logout page, which depends on both configuration settings and the particular occasion that caused the logout.

Session timeout

To save system resources, Application Server supports automatic clean up of HTTP sessions that belong to users that are no longer active. To fine tune this, the administrator can specify the time a user may be inactive (that is, issues no further requests) without being considered inactive. This time is often referred to as "idle timeout" and can be configured on a server or application basis in the Application Server. WebSphere Portal, in turn, listens to the corresponding events that are generated by Application Server on idle timeouts and stores a corresponding flag in the Portal configuration database to indicate that the user did not explicitly log out, but was automatically logged off after an idle timeout. When the user tries to directly access a protected page prior to his security session timing out as well (that is, prior to the LTPA cookie becoming invalid), WebSphere Portal can detect that the user received a new session due to the session timeout and perform the necessary actions to handle this case (which depends on the configuration).

Configuration options

Now that you have a foundation in the WebSphere Portal login and logout mechanism let's look at how you can influence the login and logout behavior by setting configuration properties. The following discussion complements what you will find in the WebSphere Portal

Information Center [6]; the focus here will be on enhancing your understanding regarding the

relevance and correlation of particular properties. Also, the Information Center describes some additional configuration properties related to the topic, especially in the area of session security and session persistence, which are not repeated here.

Changing the authentication method for the portal Web application

You can configure the WebSphere Portal authentication mechanism by changing the deployment descriptor ( web.xml

) of the wps

Web application ( wps.war

) in the Portal enterprise application ( wps.ear

). See the WebSphere Portal Information Center [6] to learn

how to modify the web.xml

in different releases and scenarios.

The authentication mechanism must be defined in the

<login-config>

element defining the login configuration. The default configuration is set to HTTP form-based authentication and looks like Listing 2.

Listing 2. Default authentication configuration

<login-config id="LoginConfig_1">

<auth-method>FORM</auth-method>

<realm-name>WPS</realm-name>

<form-login-config id="FormLoginConfig_1">

<form-login-page>/redirect</form-login-page>

<form-error-page>/error.html</form-error-page>

</form-login-config>

</login-config>

The authentication method is defined in the < auth-method>

element. Besides form-based authentication (

FORM

), WebSphere Portal also supports SSL client certificate authentication

(

CLIENT-CERT

). The < form-login-config>

element is a sub-element that is specific to the form-based authentication method and specifies the URLs to which the Application Server should redirect when enforcing a login or after an error during authentication. Therefore, you need to either comment out this block or remove it when you switch to a different authentication method.

A second aspect that is, in some cases, related to the authentication method is the transport guarantee. You can configure it separately for each security constraint in the web.xml

within the < user-data-constraint>

element.

Listing 3. Configuring the transport guarantee for a security constraint

<security-constraint id="SecurityConstraint_1">

<web-resource-collection id="WebResourceCollection_1">

</web-resource-collection>

<auth-constraint id="AuthConstraint_1">

</auth-constraint>

<user-data-constraint id="UserDataConstraint_1">

<transport-guarantee>CONFIDENTIAL</transport-guarantee>

</user-data-constraint>

</security-constraint>

If you set the transport-guarantee

element to

CONFIDENTIAL

, the Application Server enforces the HTTPS protocol when a resource protected by the corresponding constraint is requested. If you specify the value

NONE

instead, you indicate you want no enforcement on the transport layer.

The transport guarantee is especially important when WebSphere Portal is configured for the client certificate authentication method. It is the essential configuration option if you want to use both client certificate and form-based authentication at the same time:

• If the transport guarantee is set to

CONFIDENTIAL

, you can request protected resources using the HTTP protocol and rely on the automatic redirection to the HTTPS protocol and appropriate port according to the transport chain configuration in Application Server. In this configuration, you can still log in with the login portlet or login URL (because they are performing a programmatic JAAS login independent from the Application Server configuration). In this case, the protocol part of the URL is switched to HTTPS during the redirect to a protected URL that happens after the login. By default, the Application Server will then enforce client certificate authentication. The corresponding SSL repertoire must be configured this way to allow the client certificate authentication method. So, in such a setup, a login with the login portlet or login URL results in a double authentication. This double authentication must not be considered as a strictly enforced two-factor authentication. You cannot assume that the user will always be forced to provide both the certificate and the password. For example, when accessing a protected URL directly in this scenario, it is by default still sufficient to authenticate with the client certificate only.

• If the transport guarantee is set to

NONE

, protected resources can still be served with HTTP.

You can run a scenario where users log in with the login portlet or login URL and access protected URLs without being affected by SSL at all. However, you cannot use the HTTP protocol to access protected resources directly without having been authenticated before;

Application Server tries to apply the client certificate authentication without switching to

HTTPS, which results in a 403 HTTP error. In this case, the caller must manually switch to the HTTPS protocol and to the correct port to use the client certificate authentication mechanism. So, this setup lets you use the two authentication methods independently.

The official recommendation for client certificate scenarios with WebSphere Portal is to set the transport guarantee to CONFIDENTIAL and to disable the login with the login portlet and

particular login entry points).

Enabling WebSphere Portal JAAS login

As mentioned in the first part of this article, the JAAS login in WebSphere Portal login

(configuration name

Portal_Login

) is optional. By default, it is disabled; you must enable it if you want to use it. To enable it, set the property authentication.execute.portal.jaas.login

of the WP Authentication Service to true

. This property is enabled by some portal configuration tasks related to external security managers like Tivoli Access Manager, especially for externalizing portal authorization. You should only enable it manually if you want to explicitly add custom login modules to this

JAAS stack.

Switching to screen login

Before the login portlet was introduced in WebSphere Portal V5.1.0, the login was triggered from a login screen; if errors occurred during authentication, they were displayed by specific error screens. Beginning with WebSphere Portal V5.1.0, the login portlet is used as the default, but you can re-instate the old behavior, if you prefer by adjusting the authentication.screen.login

property accordingly (see reference [7] in

Resources

WebSphere Portal only supports one dedicated login screen, so it is not possible to use different login screens for individual virtual portals. The login screen is described in detail in

the Portal Information Center [7].

Reducing database traffic during login

By default, WebSphere Portal tracks some data for each user login in the WebSphere Portal configuration database. This information includes the user's last login time, and whether the

user has been logged off due to a session idle timeout (see Session timeout). Because this

tracking can lead to heavy database traffic in high load scenarios, WebSphere Portal provides a way to completely disable the persistence of this information. However, because of several implications on session timeout behavior, you cannot use it in combination with showing an error screen after a session timeout or with session persistence enabled. Therefore, to disable persistence during login, you must configure the following properties for the Portal

Configuration Service accordingly. Set:

• record.lastlogin

to false

• timeout.resume.session

to true

(each session is resumed after a timeout without showing a session time out screen, see

Influencing logout behavior

)

• persistent.session.level

(no session data is persisted)

Redirect after login or logout

The post login and post logout redirect targets can be influenced in multiple ways that can make it difficult to recognize which setting is effective in a specific situation. Tables 1 and 2 list combinations of settings and situations. All properties mentioned are properties of the

Portal Configuration Service. Property value

means that the actual value is irrelevant for this case; the value - means that this property must not be set in this combination.

For example, the first three rows of Table 1 mean: If the redirect.login property

and the redirect.login.ssl

property are set to false

and the login type is Portal (that is, you login in directly to the portal using the Login Portlet or the Portal Login screen), then the values of all the other properties are ignored except for the persistent.session.level

property. The last column in the table contains the corresponding post-login redirect behavior; it describes the target to which the user’s browser is redirected after successful login.

* true true true

Table 1. Redirect after a login re di re ct

.lo

gi n re di re ct

.lo

gi n.

ss l re di re ct

.lo

gi n.

ur l re di re ct

.lo

gi n.

au rl th en tic at ed

false false * * *

R ed ire ct

L re pa ra m et er qu es t

* se le ct io nI

r eq pa ra m et er ue st

0 pe rs is te nt

es si on

.le

ve l

Portal

T yp e of

lo gi n false false false false false true false false true true true

Portal

R es ul tin g po st

lo gi n re di re ct

Default protected page switched to

HTTP

Default protected page switched to

HTTP with the portlet states the user had chosen before logout

Last page with the portlet states the user had chosen before logout switched to HTTP

Default protected page switched to

HTTPS

Default protected page switched to

HTTPS with the portlet states the user had chosen before logout

Last page with the portlet states the user had chosen before logout switched to HTTPS

Portal after directly accessing a protected page

Protected page addressed in the URL true

* some

URL

* some

URL

* 2

* some

URL

* some page name

WAS

Portal

WAS

Portal

Protected page addressed in the UR L

Default protected page switched to

HTTP with the portlet states the user had chosen before logout

Last page with the portlet states the user had chosen before logout switched to HTTP

Given URL

The page that corresponds to the unique name "some page name"

Table 2. Redirect after a logout re di re ct

.lo

go ut re di re ct

.lo

go ut

sl re di re ct

.lo

go ut

S ed ire ct

L re qu es t pa ra m et er ur i.h

om e.

su bs tit ut io n tim eo ut

es um e.

se ss n io

* true true false -

* true

* -

some

URL

* some

URL

* * false * true

* false true

T rig r ge

Explicit logout

R es ul tin g po st

lo go ut

r ed ire ct

Default public page switched to HTTP

Explicit logout Default public page switched to HTTPS

Authenticated user accesses public page A

User requests protected page B after an idle timeout

Current user not in realm of

Virtual Portal C addressed in the request

Page A after an implicit logout

Page A rewritten to a protected page, without implicit logout

Session Timeout Screen after an implicit logout

Page B without being logged out

URL)

All triggers Given URL

Influencing logout behavior

The section Portal logout described the four possible triggers for a Portal logout. Two of them

can be influenced by settings in the Portal Configuration Service (which is indicated in the

Table 2):

• The logout that is triggered when an authenticated user accesses a public page can be switched off by setting the property uri.home.substitution

to true

. This causes

WebSphere Portal to perform a redirect to the same page using a protected URL and, therefore, prevents the logout.

• The logout enforced after a session timeout can be controlled by the setting timeout.resume.session

. If this property is set to true

, WebSphere Portal does not trigger a logout after a session timeout has been detected. This case corresponds to the

Login authenticated by ; as long as the Application Server security context has not timed,

the user is still authenticated to Application Server.

The Web Content Management logout, introduced with PK23864, can also be influenced by

properties. As indicated in Figure 4, the Web Content Management logout is an optional step.

It is enabled by default, but you can switch it off by setting the property logout.wcm

in the

Portal Configuration Service to false

. The same service also offers a property wcm.logout.jsp

that you can use to specify a string to represent the URL to the Web

Content Management logout page. This property defaults to the default Web Content

Management logout page.

Disabling particular login entry points

Some scenarios might require disabling specific direct entry points to WebSphere Portal that, by default, are active regardless of the overall configuration. This is especially relevant when you want to enforce that the user is authenticated by the Application Server (for example using client certificates), or by an external security manager.

Table 3 lists the entry points and gives a description of how you can ensure that nobody is able to access WebSphere Portal using one of them.

Table 3. Disabling WebSphere Portal entry points

Entry point(s)

To disable…

Remove the login portlet by it from all pages or completely uninstall the corresponding Web module.

(it is not possible to disable the login URL only)

XMLAccess

Use a special implementation of the

authenticated by Application Server

LoginUser

command that only enables the case described in

Login

. Set the property command.login

in the Portal Configuration Service to the value

LoginUserBlocked

Disabling this entry point implies disabling the XML configuration interface completely. This can be done by removing the servlet mapping of the XML Access servlet

Scripting Client

(servlet name config

) from the deployment descriptor or securing the XMLAccess servlet mapping URL with an empty J2EE role. Beginning with Version 6.0 of

WebSphere Portal, this servlet is located in a separate

Web application wps_xml.war

in the wps.ear

file; in earlier versions, the entry is in the web.xml

of the wps.war

Assign administrative roles in the Application Server to control which users are allowed to use the Portal Scripting

Client. Refer to the WebSphere Application Server

Information Center [8] for details.

Conclusion

This article gave you an understanding of the default WebSphere Portal login and logout behavior, capabilities, and the most relevant configuration options available. With this background, you can determine whether a particular scenario can be achieved by using

WebSphere Portal's built-in functionality and appropriate configuration settings, and you now know how to apply those to set it up. However, there are scenarios that cannot be implemented by appropriate configuration settings; these scenarios require the deployment of custom code.

Resources

[1] JAAS Documentation and Specification

http://java.sun.com/products/jaas/

[2] Exploiting the WebSphere Portal V5.1.0.1 programming model: Part 3: Integrating

WebSphere Portal into your security environment and user management system

http://www.ibm.com/developerworks/websphere/library/techarticles/0606_buehler/060

6_buehler.html

[3] Javadoc for WebSphere Portal 6.0

http://www.ibm.com/developerworks/websphere/library/specs/0608_wp6javadoc.html

[4] WebSphere Application Server 6.0.x Information Center on "Trust Associations"

http://publib.boulder.ibm.com/infocenter/wasinfo/v6r0/topic/com.ibm.websphere.base.

doc/info/aes/ae/csec_trust.html

[5] Advanced authentication in WebSphere Application Server

http://www.ibm.com/developerworks/websphere/techjournal/0508_benantar/0508_bena ntar.html

[6] WebSphere Portal product documentation, including the InfoCenter

http://www.software.ibm.com/wsdd/zones/portal/proddoc.html

[7] WebSphere Portal 6.0 Information Center on "Using screens for login"

http://publib.boulder.ibm.com/infocenter/wpdoc/v6r0/topic/com.ibm.wp.ent.doc/wpf/se c_subman.html

[8] WebSphere Application Server 6.0.x Information Center on "Administrative Roles"

http://publib.boulder.ibm.com/infocenter/wasinfo/v6r0/topic/com.ibm.websphere.base.

doc/info/aes/ae/rsec_adminroles.html

[9] developerWorks WebSphere Portal zone

http://www.ibm.com/developerworks/websphere/zones/portal/

[10] WebSphere Portal Security

http://www.ibm.com/developerworks/websphere/zones/portal/security/

About the authors

Jan-Paul Buchwald studied Computer Science at the Albert Einstein

University of Ulm. With the experience gained in a WebSphere Portal

Speed Team internship project in summer 2004, he joined the

WebSphere Portal security team after finishing his studies in 2005.

Dr. Dieter Buehler, WebSphere Portal Security Architect, joined IBM in 2002 and has worked in the WebSphere Portal development team since the WebSphere Portal 4.1 release. Prior to IBM, Dieter worked three years in research at the University of Tuebingen in Germany exploring concepts and technologies for integrating industrial automation systems into web-based portal solutions. Beyond the core

WebSphere Portal security architecture, Dieter is especially interested in Java-based client-server system design and information retrieval concepts. You can reach Dr. Buehler at

[email protected]

Thomas Hurek is a software architect at the German IBM development lab. He has technical responsibility for fix packs and Level 3 maintenance in the WebSphere Portal development team. You can contact Thomas at

[email protected]

Trademarks

• DB2, IBM, Lotus, Tivoli, Rational, and WebSphere are trademarks or registered trademarks of IBM Corporation in the United States, other countries, or both.

• Windows and Windows NT are registered trademarks of Microsoft Corporation in the

United States, other countries, or both.

• Java and all Java-based trademarks and logos are trademarks or registered trademarks of

Sun Microsystems, Inc. in the United States, other countries, or both.

• Other company, product, and service names may be trademarks or service marks of others.

Thank you for your participation!

* Your assessment is very important for improving the work of artificial intelligence, which forms the content of this project

WebSphere Portal tal Collaboration Security urity

Federated Identity Management and Web Services Security with IBM Tivoli Security Solutions

IBM WebSphere Application Server V6.1 Security Handbook Front cover

Novell Access Manager 3.1 SP2 Guide

IBM WebSphere Portal here Portal for Multiplatforms V5 V5