ShowTable of Contents
Jan-Paul Buchwald - Advisory IT Specialist IBM WebSphere Portal Lab Services
Matthias Falkenberg - Software Engineer - IBM WebSphere Portal and IBM Web Content Manager
The following requirements were considered in order to design the solution described here: Particular Portal pages should only be served using SSL. If a protocol switch is necessary to achieve the SSL protection, it should be handled without any user interaction. Also, for performance reasons, the Portal should switch back to http for resources that do not have to be served using SSL. This should work for both anonymous and authenticated access to the portal.
So with a set of pages P1 to P4, where P2 and P4 are marked as SSL only, a user interaction in the desired scenario could look like the following:
- Bob browses to P1, the page is delivered using http
- Bob navigates to P2, the page is delivered using https
- Bob navigates to P3, the page is delivered using http again
- Bob navigates to P4, the page is delivered using https again
Note: Be aware that a switch from https back to http for an authenticated user may not be desired in most real-life scenarios. Considering network sniffing attacks, even a single unencrypted http request for an authenticated user is sufficient to get hold of all the user's cookies, allowing the attacker to hijack the user's SSO and Portal session. Thus protecting only a subset of the pages for authenticated users with SSL makes only sense if you are not concerned about those kinds of attacks, but want to make sure that the communication for particular transactions is encrypted (e.g. submitting sensitive form data).
Details of the Solution
Session Validation Filter
The proposed solution leverages the session validation plug-point in WebSphere Portal to realize the scenario. The session validation plug-point is called for each Portal request and allows custom code to be executed before the action and rendering phase in Portal. The custom code can access all WebSphere Portal APIs in the context of the current Portal request and also trigger redirects to stop the processing of the request (for more details on authentication filters in WebSphere Portal see the
Infocenter
and a
developerWorks article).
The configuration whether a page must only be served with SSL is achieved using a page property for the Portal page that is evaluated by the filter implementation.
Reasons for not using Step-up Authentication for this scenario
Discussions and considerations when designing the solution also pointed to the step-up authentication framework in WebSphere Portal, which might appear as a simpler and more elegant approach to realize the scenario in the first place. This approach has been analyzed, too, but we preferred the approach with the session validation filter for the following reasons:
- The idea behind step-up authentication in WebSphere Portal is to augment the authentication strength with each authentication level and keep an acquired authentication level until the end of the user session. Thus it is not possible to realize SSL protection for anonymous and authenticated users with a single authentication level, as for anonymous SSL pages you would need a level below the "authenticated" level, and for authenticated SSL pages a level above the "authenticated" level. Using several authentication levels for SSL protection (like "SSL for public pages", "SSL for protected pages") would be possible, but besides making the administration more complex this would mean that authenticated users could view pages that are protected with the authentication level "SSL for public pages" over http.
- For similar reasons, the switch back to http for a non-SSL page can not be triggered from the step-up authentication framework as there currently is no concept for a "step-down".
SSL detection
Detecting whether the end user used a secure connection is not as straightforward as it seems: Calling the method
isSecure() on the
HttpServletRequest loses its reliability as soon as a proxy server or an HTTP server is installed between the client and Portal. This is because the intermediate server could in fact use a secure connection to Portal, while the client communicates with the intermediate server unsecured. Therefore, in this solution an HTTP cookie is employed to indicate the end-to-end security. Cookies can be flagged as secure by setting the attribute "Secure" with no value. According to the
RFC 2965 a client must use secure means to send back secure cookies to the originating server in order to ensure the confidentiality of the contained information.
Description of the Sample Code
The sample code basically consists of the custom session validation filter class com.ibm.portal.sample.SSLSessionValidator. The custom filter logic is best illustrated in the following diagram: The code first checks whether SSL is required for the current page by reading the respective page property for the page addressed in the current request, and whether the secure cookie is available in the request from the client. If SSL is required, but there is no secure cookie in the request, the filter sets the secure cookie on the servlet response and triggers a redirect to the secure URL. Otherwise, if SSL is not required for the current page, but there is a secure cookie, the filter performs a protocol switch back to http by triggering a redirect to the non-secure URL. If both those conditions are not met, the filter dispatches to the default Portal request processing, so the Portal page is rendered as usual.
The filter has been implemented in a configurable way in order to allow flexible definitions for the name of the page property to enforce SSL protection and the secure cookie characteristics like cookie name, domain, path, and expiration. The code makes use of several public WebSphere Portal APIs, namely the Navigation Selection Model to retrieve the target page addressed in the current request, the Content MetaData Model to load the page property, and the Portal State Manager Service to generate a new URL according to the current navigational state. For the detailed implementation, find further explanations in the code comments or logging statements. Besides the filter implementation class, the sample code provides two exception class implementations that do not contain any logic, but just pass on another exception as the cause.
You can download the sample code as a compressed Rational Software Architect project
on Greenhouse (Greenhouse login/registration required). The project requires the WebSphere Portal 6.1 or newer server runtime library and the
wp.auth.base.jar from the
/base/wp.auth.base/shared/app in the build path.
The sample code has been tested with WebSphere Portal version 6.1.5 and 7.
Configuration of the Filter
To use the custom session validation filter, perform the following steps:
Export the project as a JAR file and place it in the WebSphere Portal class path (for example, /shared/app).
Set the following property in the
WP AuthenticationService resource environment provider (if this property already has a value defined, add the value below before the existing value separated by a comma)
sessionvalidation.filterchain = com.ibm.portal.sample.SSLSessionValidator
Optionally, set the following other properties in the
WP AuthenticationService resource environment provider to change the settings for the SSL page property or the secure cookie:
filterchain.properties.com.ibm.portal.sample.SSLSessionValidator.sslRequiredProperty // Name of the page property to specify that a page requires SSL (default: SSLRequired)
filterchain.properties.com.ibm.portal.sample.SSLSessionValidator.secureCookieName // Name of the secure cookie (default: com.ibm.portal.SSL)
filterchain.properties.com.ibm.portal.sample.SSLSessionValidator.secureCookieDomain // Domain of the secure cookie (default: no domain set)
filterchain.properties.com.ibm.portal.sample.SSLSessionValidator.secureCookiePath // Path of the secure cookie (default: /)
filterchain.properties.com.ibm.portal.sample.SSLSessionValidator.secureCookieMaxAge // Number of seconds after which the secure cookie expires (default: -1, i.e. does not expire)
To make sure the URL generation of the redirect URLs works properly, verify that the following properties in the WP ConfigService resource environment provider are correctly set for your environment:
host.name // Fully qualified host identifier in a Portal URL
host.port.http // port number for HTTP connections
host.port.https // port number for HTTPS connections
Note: In setups with multiple virtual portals that are defined by different virtual host names, the host.name property only applies to the base portal. When the session validation filter is called in the context of a virtual portal, the Portal APIs that are used to generate the redirect URL automatically detect that case and set the correct virtual host name according to the virtual portal.
All properties require a server restart to become effective.
Once the filter has been configured, set the SSL page property and the value "true" as a name value pair in the page parameters either in the Portal administration interface (via "Manage Pages" - "Edit Page Properties" - "Advanced Options" - "I want to set parameters", see pictures) or using XML Access. Note that child pages by default inherit the property from their parent page, so it must not be explicitly set for each page to protect a whole subtree of the portal page hierarchy. However, the property can be overwritten explicitly to specify a different value.
Usage Example
Create two Portal pages
SSLTestPageAnonymous and
SSLTestPageAuth. Make the
SSLTestPageAnonymous a public page (by assigning the "User" role to the anonymous user), and the
SSLTestPageAuth a protected page (by making sure the anonymous user does not have any permissions on it). For both pages, set the page property for SSL protection as described above. Then verify that the protocol in the browser's address bar changes to https when you navigate to one of the two pages, and switches back to http when navigating back to other pages that do not have the page property set.