IBM WebSphere Portal V6.0 Security Overview

WebSphere Portal 6.0 Security, Version 6.0.0
IBM WebSphere Portal V6.0 Security Overview
Level: Advanced
Dr. Dieter Buehler, WebSphere Portal Security Architect, IBM
Stefan Schmitt, WebSphere Portal Security Lead, IBM
Holger Waterstrat, WebSphere Portal Security Team, IBM
Andreas Zehnpfenning, WebSphere Portal Security Team, IBM
Jan-Paul Buchwald, WebSphere Portal Security Team, IBM
Richard Jacob, WebSphere Portal WSRP Lead, IBM
Thomas Hurek, WebSphere Portal L3 Lead, IBM
01 Nov 2006
© Copyright International Business Machines Corporation 2006. All rights reserved.
Abstract
Portals provide personalized access to information, applications, processes, and people. They are
central access points that authenticate users and control access to various kinds of information and
applications. The nature of the content of portals can range from public information that needs no
strong protection (such as articles in a news portal) to classified information within enterprises or
governments.
To accommodate such different levels of security requirements, IBM® WebSphere® Portal must
integrate with different security infrastructure components for authentication, authorization, and
single sign-on (SSO) so that customers can choose the combination that best matches their
security needs. For example, authentication might be as simple as requesting users to provide a
user ID and password. Alternatively, it could be as sophisticated as requiring users to authenticate
using a smart card, which securely stores a private key and certificate. The card provides
WebSphere Portal with cryptographic computations needed to participate in SSL/TLS client
authentication to build up an authenticated and secure connection between the client and the
portal.
Through its modular architecture, WebSphere Portal enables integration with different
authentication proxies, authorization systems, and credential vault implementations. WebSphere
Portal can work with WebSphere Security, Tivoli Access Manager, and various third-party security
products. It lets customers build a secure system that fits well into their particular infrastructure.
This article provides portal administrators with an overview of the WebSphere Portal security
architecture, and briefly describes some basics of internet security. You see various deployment
scenarios for WebSphere Portal through which you learn how it handles authentication,
authorization, SSO, secure connections between clients and the portal, and secure connections
between the portal and back-end systems.
Page 1 of 50
WebSphere Portal 6.0 Security, Version 6.0.0
Table of contents
1 Introduction......................................................................................................... 4
1.1 Revisiting basic Internet security ................................................................... 6
1.1.1 Protected communication.................................................................................................. 6
1.1.2 Firewalls............................................................................................................................ 7
2 Portal deployment scenarios............................................................................. 8
2.1 Portals in protected networks.......................................................................... 8
2.2 Internet portals................................................................................................ 8
2.2.1 Portals using WebSphere Application Server authentication............................................. 9
2.2.2 Portals using a separate authentication proxy................................................................... 9
3 Authentication................................................................................................... 11
3.1 Authentication using WebSphere Application Server Security...................... 12
3.2 Authentication using a separate authentication proxy .................................. 13
3.2.1 Trust Association Interceptor........................................................................................... 13
3.3 Requests in a session which is already authenticated.................................. 15
3.4 User registry.................................................................................................. 16
3.5 Portal login.................................................................................................... 17
3.6 JAAS login.................................................................................................... 17
3.7 Logout........................................................................................................... 18
3.8 Customizing the portal login and logout processes....................................... 19
4 Single sign-on (SSO)........................................................................................ 19
4.1 SSO from the client to Web applications....................................................... 20
4.1.1 SSO between Windows workstations and the portal....................................................... 20
4.2 Portal-to-back-end SSO................................................................................ 21
4.2.1 How the Credential Vault works....................................................................................... 21
4.2.2 Passive and active credential objects.............................................................................. 22
5 Securing client-to-portal communication....................................................... 25
5.1 Restricting the protection to sensitive communication only .......................... 28
5.2 Using client certificates................................................................................. 28
6 Securing back-end connections...................................................................... 29
6.1 Using IPSec between the portal and back-end applications......................... 29
7 Controlling access to portal resources.......................................................... 29
7.1 Access control concepts............................................................................... 29
Page 2 of 50
WebSphere Portal 6.0 Security, Version 6.0.0
7.1.1 Sensitive operations........................................................................................................ 29
7.1.2 Protected resources......................................................................................................... 29
7.1.3 Roles and role types........................................................................................................ 30
7.1.4 Role assignment and inheritance..................................................................................... 32
7.1.5 Role blocks...................................................................................................................... 33
7.1.6 Resource ownership........................................................................................................ 33
7.1.7 Private pages................................................................................................................... 33
7.1.8 Resource domains........................................................................................................... 33
7.2 Delegating access control administration...................................................... 35
7.3 Access control in the composite application infrastructure (CAI).................. 35
7.4 Integrating external authorization systems.................................................... 36
7.5 Administering access control........................................................................ 37
7.5.1 Administering access control using the XML Configuration Interface.............................. 38
7.5.2 Administering by using Scripting...................................................................................... 39
7.6 Auditing......................................................................................................... 40
8 Portlet security.................................................................................................. 41
8.1 Supporting Java 2 Platform Security............................................................. 41
8.2 Verifying secure connections........................................................................ 42
8.3 Preventing cross-site scripting attacks.......................................................... 42
8.4 Dangerous URL Protection........................................................................... 42
9 WSRP Security.................................................................................................. 43
9.1 Securing connections to remote portlets....................................................... 43
9.1.1 Securing WSRP services on the Web Service layer........................................................ 43
9.1.2 Securing WSRP services on the transport layer.............................................................. 45
9.2 Enforcing access control with WSRP security.............................................. 45
9.3 WSRP security and the Credential Vault...................................................... 46
9.4 WSRP and Cross Site Scripting.................................................................... 46
10 Summary......................................................................................................... 46
11 Resources....................................................................................................... 47
12 About the authors........................................................................................... 47
13 Glossary.......................................................................................................... 48
14 Product names................................................................................................ 48
15 Acknowledgements........................................................................................ 49
Page 3 of 50
WebSphere Portal 6.0 Security, Version 6.0.0
1 Introduction
This document provides an overview of security concepts and the mechanisms in IBM WebSphere
Portal V6.0 which secure access to portal resources such as page groups, pages, portlets, and
documents. It describes WebSphere Portal options which portal administrators can use to provide
user authentication and authorization, and to support single sign-on (SSO).
Figure 1 illustrates the most important components in WebSphere Portal [1], which are invoked
(from left to right) when handling requests for portal pages. While there could be some public portal
pages which are accessible without prior Authentication, all requests for personal pages or group
pages must pass through an authentication component, such as IBM WebSphere Application
Server Security, Tivoli Access Manager, or third-party security products. After a user is successfully
authenticated, the request is analyzed and routed to the appropriate component where it is
handled.
Page 4 of 50
WebSphere Portal 6.0 Security, Version 6.0.0
Figure 1: WebSphere Portal subsystems
Incoming HTTP requests that want to obtain a portal page are routed to the Portal Servlet which
acts as the central access point to all portal pages. The requests must be authorized. The
component receiving the request calls the authorization component to determine whether access
can be granted. Authorization information to most portal resources is maintained within the portal
so that semantic consistency of access rights is guaranteed. However, for some resources, access
control can be externalized to systems such as IBM Tivoli Access Manager or Netegrity SiteMinder.
When a request is routed to the portal servlet and access to a page is granted, the valid subset of
portlets that are referenced on the page is determined. Only those portlets for which the user has
sufficient access rights will be invoked.
Next, the servlet selects the appropriate aggregation module based on the request’s user agent
information. The aggregation module renders the page by calling the referenced portlets using the
Portlet API, enriching the request information with user profile information from the Member
Services component and with portlet instance data from the WebSphere Portal data store.
Portlets are special servlets which, unlike other servlets, are designed to participate in the portal’s
event model and to exploit the portal infrastructure. Therefore, a portlet can invoke any J2EE
function such as JCA Connectors, Enterprise Java Beans, Message Beans, and JDBC. A portlet
can call Web services and HTTP URLs (just as other servlets can). In addition, it can invoke portalspecific portlet services and tag libraries from within JSPs.
Portlets are often used to integrate back-end applications into a portal, providing a Web-based user
interface. In such a scenario, Single Sign-On (SSO) is an important requirement. After logging into
the portal, users do not want to enter passwords for each application the portlet needs to access
from a back-end system. To support SSO to portlets and their associated back-end applications,
WebSphere Portal provides a Credential Vault portlet service. Portlets can use the service to obtain
and forward credentials to back-end systems to transparently authenticate the user underneath the
covers. The credential vault service is backed by a credential vault, which can either be the portal’s
built-in vault or IBM Tivoli® Access Manager’s secure vault.
Page 5 of 50
WebSphere Portal 6.0 Security, Version 6.0.0
1.1 Revisiting basic Internet security
Because the Internet is open to everybody, communication through it is exposed; systems
connected to the Internet need to be protected.
The IP packets that make up all Internet traffic can be monitored, copied, and modified. This poses
various threats, such as eavesdropping, sending of messages or mail with false origin, or alteration
of the message content. To prevent those attacks on communication, various encryption
techniques are used on different layers of the network protocol stack. The most widely used
techniques are IPSec protection of the IP packets in the link layer and the transport layer security
protocols (TLS), and its predecessor, secure sockets layer (SSL).
1.1.1 Protected communication
The current version of the IP protocol is version 4 (often abbreviated as IPv4). The next version is
version IP version 6 (IPv6), which provides new features including an enormously extended space
of available addresses. IPv6 will also offer protection of the IP packets by means of encryption and
signing. You can get these security enhancements with IPv4, using the extensions called IPSec [2].
Any kind of protected communication requires the use of cryptographic keys at both the sender and
receiver. In IPv6, the management of these keys will be flexible enough to allow for easy adding of
new communication nodes. In contrast, several of the current IPSec implementations limit the
flexibility and complexity by, for example, using shared secret keys instead of private and public
keys. When using implementations with such limitations, IPSec is better suited to protect the
communication between statically coupled1 network nodes.
Transport Layer Security (TLS) and its predecessor Secure Socket Layer (SSL) apply the
protection of data confidentiality to a higher layer of the communication [3]. They also
unconditionally use private and public keys for authenticating the communication partners. A
communication partner uses the private key to prove its authenticity to the other partner, who, in
turn, uses the corresponding certificate to verify authenticity.
TLS and SSL allow three degrees of authentication:
•
No authentication - makes the communication immune against eavesdropping, but it cannot
prevent one partner from communicating its data to an unintended receiver, thus exposing the
data.
•
Authentication of the server to the client - protects the client from exposing its data to an
unintended receiver.
•
Mutual authentication - protects the server from serving to unauthorized clients. It requires that
both the server and the client have a certificate with the associated public and private key.
To prevent misuse of the private key (especially to copy it), you must protect the key--ideally by
using special-purpose cryptographic hardware. While it is common today to have a valid public key
certificate and a secure key storage for servers, this mechanism is still not widely used with clients.
For encryption of the transmitted payload, TLS and SSL use symmetric key cryptography, because
the symmetrical cryptography algorithms perform much faster than public key cryptography
algorithms. To agree on the shared symmetrical key (called the “session key”), both partners
employ public key cryptography during the initial session setup.
1
That is, nodes for which the coupling will not change frequently, such as between an authentication proxy
and the associated user registry.
Page 6 of 50
WebSphere Portal 6.0 Security, Version 6.0.0
1.1.2 Firewalls
In the physical world, we protect areas by fences and walls, making it harder for unauthorized
persons to intrude. At the same time, it is a bit harder for the authorized persons to enter too. The
fences and walls need to be maintained and the distribution of the keys must be controlled.
In the world of networks, we protect parts of the network by inserting firewalls between them and
the rest of the network. These firewalls filter and monitor the network traffic, making it harder for
unauthorized persons and programs to access any node in the protected network area. At the
same time this protection restricts flexibility and adds cost for the maintenance of the firewall and its
policies (very similar to physical world access control).
The basic filter function of standard Internet firewalls operates on IP packets. A packet is forwarded
or dropped, depending on its origin and destination. The port of the origin and the destination is
included in the decision. This allows basing the filtering also on the service requested, because the
services are bound to specific port numbers. The filtering policies can be configured as a set of
rules.
Basic IP packet filtering is most efficient but provides only limited protection. More sophisticated
analysis of the communication is needed to enable better flexibility without compromising security.
Packet filtering technology is constantly enhanced to add understanding and analysis of the
packets with an understanding of the higher protocol layers they carry. A packet might well be legal
in the context of its preceding IP packets, but would need to be rejected just on its own. A firewall
capable of “stateful packet filtering” can understand the context of a packet within a larger section
of the overall communication. For example, a filter configuration might only allow inbound traffic
from the external network if it is a response to an HTTP request, which had passed the filter
outbound before. This stateful form of packet filtering is called “dynamic” to distinguish it from the
basic “static” packet filtering.
Another filtering principle used by firewalls is “circuit filtering”, which can correlate requests and
responses. Circuit filters achieve this additional intelligence by acting as proxies on the TCP layer.
Filtering at a higher layer is also performed by “application gateways”, which understand and
analyze the traffic on the application layer and filter it even more intelligently. For example, an
application gateway can reject inbound or outbound mail with certain contents. This firewall
technique can provide the tightest protection but takes the highest toll in terms of processing
resources and administration.
A firewall might perform a Network Address Translation (NAT) from externally published addresses
to private internal addresses. This translation protects the inner systems, because outsiders do not
know these private addresses. At any rate, they could not use these addresses remotely because
they are in a range that a router would not treat as a legal destination.
Another level of capability is a firewall’s ability to participate in an intrusion detection scheme.
Rather than silently dropping suspicious packets, a more sophisticated firewall can make these
events known to the intrusion detection system, which can perform more analysis and generate an
alert, if needed.
Most companies are using more than a single firewall to shield the inner network from the Internet.
Often, an outer firewall separates the Internet from the so-called Demilitarized Zone (DMZ). Only
those nodes which need to be visible to the Internet are located in the DMZ. A second firewall
separates the DMZ and intranet. This inner firewall is configured to allow inbound traffic only from
machines in the DMZ that have been explicitly authorized.
Two firewalls and one DMZ is a widely used approach. Often three firewalls and two DMZs are
used. You could compare this to a ship’s body which is built in segments to make it less sinkable.
Water penetrating the hull might fill one segment, but not the others. Intruders who were able to get
into one segment of the network should not be able to easily get into other segments.
For excellent advice on the use of firewalls we recommend reading Guidelines on Firewalls and
Firewall Policy, Recommendations of the National Institute of Standards and Technology [4].
Page 7 of 50
WebSphere Portal 6.0 Security, Version 6.0.0
2 Portal deployment scenarios
When planning a portal system based on WebSphere Portal, you have a variety of possible
deployment options, each of which provides different levels of performance, scalability, availability,
and security. In this section, you see some typical portal scenarios and learn about the security
considerations for the applicable deployment options.
2.1 Portals in protected networks
First, take a look at a simple portal setup, which is applicable if the portal and its clients reside in a
protected network, under the assumption that no attacks are to be expected from within this
network2. Portal and clients are protected by a firewall and are, therefore, not visible to the Internet,
as shown in Figure 2. The bold red border depicts a firewall.
Figure 2: Deployment of a portal within a protected network
Clients can connect to the portal server directly because they are in the same network. In this
example configuration, we assume that the Web server and the application server with the portal
server code are located on the same physical machine. The portal uses a database on a separate
server for storing its data. All user information is in a user registry on a third machine. The portal
server, the database server, and the user registry are all in the same network. Also, in the same
network are all of the back-end systems which the portal applications might access.
2.2 Internet portals
For portals servicing clients in the Internet, the simple firewall protection described in the previous
section is not sufficient. At least one node of the portal system must be visible from the Internet.
2
The assumption that no attacks are launched from within an intranet is very rarely valid. Such a setup,
although common practice, is not recommended.
Page 8 of 50
WebSphere Portal 6.0 Security, Version 6.0.0
Two or more firewalls are typically used to segment the server environment into different security
zones. We will explore a few variations in the following sections.
2.2.1 Portals using WebSphere Application Server authentication
If the portal handles authentication and access control of its resources, the machine running the
Web server needs to be visible to the Internet, as shown in Figure 3. In this example, we assume
that the Web server and the application server with the portal server code are located on different
machines. The Web server is the first node that needs to be accessible for external clients and,
therefore, must be visible to the Internet. It is located in a DMZ behind an outer firewall, allowing
HTTP requests to the Web server as the only incoming traffic.
Figure 3: Portal configuration example serving clients in the Internet
A second firewall provides additional protection for the inner network and the back-end systems. It
allows only the expected inbound traffic from the Web server to the portal server. In order to
penetrate through the second firewall an attacker must first have succeeded in seizing control of
the Web server. To allow the portal server to access and aggregate external content, an outbound
proxy in the DMZ forwards requests from the intranet, and returns the responses from the Internet.
Additional firewalls to segment the intranet might be used but are not shown here.
2.2.2 Portals using a separate authentication proxy
For authentication, WebSphere Portal can either use its own authentication mechanism (that is, the
authentication mechanisms provided by the security infrastructure of WebSphere Application
Server) or rely on a separate authentication proxy server. A separate authentication component
can provide a single central authentication point for one or more portals and other web resources.
Page 9 of 50
WebSphere Portal 6.0 Security, Version 6.0.0
The authentication proxy server can be implemented as a separate server machine, as a plug-in to
the Web server, or as a plug-in to the Edge component in WebSphere Application Server
(previously known as the Edge Server).
Figure 4 shows an example of a portal deployment with a separate authentication component. In
this example, a proxy server handles the authentication. This authentication proxy is the only node
visible to clients connecting from the Internet. It is protected by an outer firewall. To decide whether
a request can be allowed to pass through, the authentication proxy cooperates with its
authorization server, which is behind another firewall. This firewall only allows inbound requests
from the authentication proxy and inbound responses from the outbound proxy. The outbound
proxy forwards requests from the intranet and returns the responses from the clients in the Internet.
The authorization server accesses the user registry, which is in the same network. In this example,
the user registry is used by the authorization server, the portal server and by other systems.
The portal server functions execute on several machines in a cluster to provide a higher capacity
and fault tolerance. Figure 4 shows three server machines that indicate the cluster, which could
decompose into a load balancer machine, several caching proxy machines, and several portal
server machines.
Figure 4: Example of a portal deployment with separate authentication component
In the same network − along with the authorization server, user registry, and portal server cluster −
are the portal database, content management server, and search server. Another firewall separates
this network from the intranet clients.
2.2.2.1Portal clusters with load-balanced authentication proxies
The last deployment example we look at is a portal cluster, which uses a separate a load-balanced
and fault-tolerant cluster of authentication proxy server machines (Figure 5).
The network node visible to the clients in the Internet is the load balancer, which dispatches
requests between several authentication proxies. These proxies are located in the DMZ so that
only authenticated requests get through the second firewall into the production network.
Page 10 of 50
WebSphere Portal 6.0 Security, Version 6.0.0
The portal server cluster is placed in the production zone behind the second firewall, along with the
portal database, the search server, and the content management server. A third firewall separates
the portal server cluster network and back-end systems from the intranet clients.
Figure 5: Portal deployment with clusters of portal servers and authentication proxies
In this example, you see a typical network administration setup with a separate administration
zone. We assume that the middle firewall has been given a third network adapter to connect the
administration network with the outer DMZ and the production network in a secure way using
customized filtering. Inside the administration network is the authorization server, the user registry,
the network administration system, and the Intrusion Detection System (IDS).
3 Authentication
The precondition for access control is to make sure that the person or program requesting access
is identified without doubt. This process is called authentication. In its most common form,
authentication employs a user identification string (user ID) and a user secret (password) to
establish certainty about the requestor. The standard ways to supply the user ID and password to
the server are HTTP basic authentication (a Web browser mechanism using a standard login
dialog), or HTTP form-based authentication (a mechanism in which the server sends a customized
authentication form that is presented to the user). Other authentication mechanisms include
SSL/TLS client authentication based on digital signatures and certificates (including secure storage
on smart cards), hardware-based one-time passwords such as the RSA SecureID token, and
various biometric mechanisms such as finger print verification, iris scanning, or speaker verification.
The WebSphere Portal authentication subsystem delegates the task of authentication to underlying
mechanisms of WebSphere Application Server [5,6]. It provides support for the following
authentication configurations:
Page 11 of 50
WebSphere Portal 6.0 Security, Version 6.0.0
•
Use of native WebSphere Application Server authentication. A custom login form posts
the user’s authentication data to a servlet which requests WebSphere Application Server
Security to validate the user’s authentication data. Alternatively, you can set up
WebSphere Application Server to accept and validate SSL client certificates. This setup
exploits the fact that WebSphere Portal is well integrated with WebSphere Application
Server and that the portal can be configured as a secure Web application.
•
Use of an authentication proxy. WebSphere Application Server provides an interface that
allows it to establish trust to authentication proxies; this interface is called the Trust
Association Interceptor interface.
Let's look at both of these configurations.
3.1 Authentication using WebSphere Application Server Security
To use WebSphere Application Server Security, the portal is configured as a secure Web
application. When WebSphere Application Server receives a request for this application (the
portal), its security component requests the authentication credentials from the client. Depending
on which authentication method you configured, one of the following occurs:
•
An HTTPS client certificate request is sent to the browser, or
•
The client is redirected to an authentication form that prompts the user to provide the
credentials for authentication.
In the latter case (which is the portal default configuration), the form posts the credentials to
WebSphere Portal’s custom authentication servlet which obtains the posted credentials. The
servlet then logs the user in to WebSphere Application Server’s security context using the JAAS
(Java Authentication and Authorization Services [7]) Framework, as described in JAAS Login.
In the case of HTTPS client certificate authentication, WebSphere Application Server receives the
authentication credentials directly.
WebSphere Application Server authenticates the user by checking the provided credentials against
the user registry, which can either be an LDAP directory or a custom user registry. Figure 6 shows
the detailed flow of control when a request for a portal destination is not yet authenticated, and
needs to be authenticated by WebSphere Application Server Security. In this example, the
configuration was set up to use HTTP form based authentication.
The post-login page can be configured as part of the post-login redirection policy.
Page 12 of 50
WebSphere Portal 6.0 Security, Version 6.0.0
Figure 6: Authentication flow with WebSphere Portal configured to use WebSphere
Application Server Security and HTTP form-based authentication
3.2 Authentication using a separate authentication proxy
You can use an external authentication proxy to protect the portal by intercepting all requests
targeted for portal destinations. An authentication proxy can be implemented as a proxy server
such as WebSEAL in IBM Tivoli Access Manager for e-business [8]. Alternatively, it can be
implemented as a plug-in to the Web server or to the IBM Edge Server. Examples of HTTP plug-in
authentication proxies are the Web Agent in Netegrity SiteMinder, and the authentication plugin
within Entrust GetAccess. The IBM Tivoli Access Manager Plugin for Edge Server plugs into Edge
Server instead of into the Web server.3
An external authentication component authenticates users by whatever means the external
authentication component considers appropriate (for example, using an LDAP BIND call). You can
use Trust Association Interceptors, registered with WebSphere Application Server, to establish a
trust relation between WebSphere Application Server and the external authentication component.
The authentication component passes the authenticated user ID string to WebSphere Application
Server (for example, encoded in dedicated HTTP headers) which will accept the user ID based on
the established trust. A typical way of establishing this trust is using a shared secret to encrypt and
decrypt the user ID when stored and retrieved from the HTTP request (such as the HTTP header
fields mentioned earlier). This is a common scenario in production environments.
3.2.1 Trust Association Interceptor
A Trust Association Interceptor (TAI) is a mechanism by which WebSphere Application Server
enables an external component to authenticate the user and to assert the identity to the
WebSphere Application Server Web container.
3
Plugging into the Edge Server has advantages for scalability.
Page 13 of 50
WebSphere Portal 6.0 Security, Version 6.0.0
WebSphere Application Server provides functions which the TAI uses to indicate that it is able to
handle a request and that the request is already authenticated. You could think of a TAI as an
adapter, which communicates with the authentication component in an unspecified way and makes
the authentication decisions accessible to WebSphere Application Server through the specified TAI
interface.
Figure 7: Supported authentication components and Trust Association Interceptors
After a request for a portal destination passes the external authentication component, WebSphere
Application Server receives it and passes it sequentially to the registered TAIs. If one of the TAIs
indicates that it is responsible for authentication, it either accepts or rejects the request.
If no TAI can handle the incoming request, WebSphere Application Server falls back to its native
authentication, just as if there where no TAIs at all. In the case of WebSphere Portal, the client is
redirected to the custom login form. However, this should only occur with requests that bypass the
external authentication component.
Figure 8 shows the detailed flow of control for a request that passes through an external
authentication proxy. The interactions shown are the same for authentication proxies implemented
as separate servers, or for proxies implemented as plug-ins for the Web server or the Edge
component.
Page 14 of 50
WebSphere Portal 6.0 Security, Version 6.0.0
Figure 8: Flow of control for a request passing through an external authentication proxy
3.3 Requests in a session which is already authenticated
After successful authentication (through either WebSphere Application Server Security or an
authentication proxy with a TAI) the user is logged in. Then, the user's authenticated portal session
starts and an SSO token is issued to the client as a cookie, along with the HTTP session cookie
(usually named JSESSIONID)4.
The default implementation used for the SSO cookie is the Lightweight Third Party Authentication
(LTPA) scheme supported by the WebSphere components. As proof of authentication, user
information is signed and encrypted into an LTPA token, which can be verified by all servers that
are part of this LTPA SSO domain. An LTPA token contains the user ID and has an expiry date and
time, at which time it expires (even when continuously used).
It is possible to use custom SSO tokens to obtain trust between calls from the client.
4
For devices that cannot manage cookies (like WAP phones), proxy gateways take over the handling of
cookies.
Page 15 of 50
WebSphere Portal 6.0 Security, Version 6.0.0
Figure 9: Flow for a request that is already authenticated
3.4 User registry
The user registry is a repository that holds information about registered users and groups.
WebSphere Application Server and WebSphere Portal support an internal WebSphere Portal
database, an LDAP directory, or a custom registry as a user registry. WebSphere Portal shares the
authentication registry with WebSphere Application Server and can also (optionally) have a
separate look-aside database for user profile data and preferences. Some profile information can
also be stored in the same physical store as the authentication registry. For example, an LDAP
directory typically contains much more information about each user than just the name and
password.
In WebSphere Portal, the information about users is centralized in the WebSphere Member
Manager (WMM) component. You can configure this WebSphere Portal component for different
layouts of data in the user registry and its look-aside database. Also, WebSphere Portal can work
with a read-only user registry, in which case, all portal user data that needs to be updated is stored
in the internal look-aside database.
The WebSphere Member Manager component is also responsible for determining group
membership. This information is used by WebSphere Portal’s access control component and
administration functions. The lookup is able to evaluate nested groups. Because this lookup has a
potential impact on performance, a configurable option lets you stop group membership lookup at
the first level.
The supported authentication registries and their corresponding Application Server and WebSphere
Portal settings are listed in the following table:
WebSphere
Member Manager
configuration
WebSphere
AppServer
authentication
registry
LDAP + database
LDAP or
Description
The authentication registry is a directory server
(LDAP), and profile information is split between
custom registry for
both LDAP and a database. The degree of this
WebSphere Application
split is configurable (for example, what attributes
Server provided by
are stored in LDAP and what in the database).
WebSphere Portal
This configuration is possible either with the
WebSphere Application Server LDAP registry or
a custom user registry implementation for an
LDAP user registry provided by WebSphere
Portal. The custom registry has the advantage of
supporting the realms notion required for
different user populations with Virtual Portal.
Page 16 of 50
WebSphere Portal 6.0 Security, Version 6.0.0
Multiple
repositories
Custom registry for
The authentication registry can be a combination
WebSphere Application of one or multiple directory servers (LDAP) and a
Server provided by
database.
WebSphere Portal
This configuration is only possible with a custom
user registry implementation for an LDAP user
registry provided by WebSphere Portal.
This setup does let you create a horizontal split
of the user registry.
Database only
Custom registry for
WebSphere Application
Server provided by
WebSphere Portal
WebSphere Portal provides a custom user
registry implementation for the internal database.
With this configuration, the authentication
registry is part of the Member Manager, and
profile information is stored in the same
database.
Customer provided
Custom registry for
The customer supplies a custom user registry.
WebSphere Application Profile and authentication information is held in
Server provided by
this custom registry.
customer
3.5 Portal login
After authentication to WebSphere Application Server, the portal login is performed. The portal
login accepts the authenticated user ID string from the WebSphere Application Server security
context and initializes the portal’s HTTP session with corresponding user data:
1. The user profile data is populated from the user registry.
2. The user session is resumed from the saved state (if this option was chosen).
3. The browser is redirected to post-login target page.
In addition, you can configure your portal to perform a second portal-specific JAAS login to
populate the portal user object with additional credentials. (See also JAAS login.)
When the user terminates the session, he or she can either explicitly perform a logout action, or the
session can time out. For more detail, see Logout.
3.6 JAAS login
If you choose form-based login as the authentication mechanism for your portal, a JAAS login
triggers the Application Server authentication to build the Security Context. A JAAS login is also
triggered for the portal login.
JAAS, a Java API for authentication and authorization, specifies three different categories of
classes: common, authentication, and authorization. WebSphere Portal mainly uses the common
classes (in particular, the JAAS Subject). Some of the functionality of the authentication classes
(LoginContext and LoginModule) is used, and none of the authorization classes are used.
A JAAS login as defined by the JAAS specification executes a number of login modules and returns
the user’s Subject as a result of a successful login. The Subject is a container for the user’s
identities (Principals) and Credentials. Each login module can add principals and/or
credentials to this Subject.
Figure 10 shows an example of a JAAS login flow.
Page 17 of 50
WebSphere Portal 6.0 Security, Version 6.0.0
During Application Server authentication, a JAAS configuration executes which contains the
Application Server modules performing the authentication against the configured user registry. The
JAAS configuration also contains a module which builds the SSO token for authentication of
subsequent requests. You can adapt the configuration by adding additional login modules before or
after the execution of the Application Server login modules. These additional modules could
establish a secured state in the shared State (of the login modules) to disable authentication to the
user registry. More information on the WebSphere Application Server login modules can be found
here [9].
An individual JAAS login module can get the actual HTTP Request and HTTP Response objects
that triggered the JAAS login using corresponding JAAS Callbacks supported by WebSphere
Application Server. The JAAS configuration that executes the login is also triggered for
authentication of XmlAccess and portal scripting requests.
During the optional portal JAAS login, the user does not need to be authenticated because user
authentication was previously performed by the authentication component (either Application
Server Security using an authentication proxy, or by the first JAAS login). Therefore, the
WebSphere Portal JAAS login modules typically only populate the user’s JAAS Subject. This can
be used to store single sign-on tokens which can then be used by special active credential objects
(see Passive and Active credential objects) to enable portlets to access other applications within
the same single sign-on domain. (See SSO for more information on single sign-on).
The JAAS configuration used for Application Server Authentication is registered with the name
Portal_LTPA; the JAAS configuration used for portal login is registered as Portal_Login.
Figure 10: Sample JAAS Login
3.7 Logout
The logout can be initiated by a URI that is explicitly selected when the user clicks on the logout
button (which has been added by the aggregation engine to every page banner). Alternatively, the
Page 18 of 50
WebSphere Portal 6.0 Security, Version 6.0.0
logout can be initiated implicitly through a session timeout that occurs after a specified time of
inactivity.
The portal logout performs the following actions:
1. Suspend User Session. The user’s portal session (the portal’s navigational state) is
persisted. The HTTP session is invalidated.
2. Portlet user logout. The portlets are notified of the event “user logged out” to give them the
opportunity to finalize (trans-)actions that need to be terminated.
The following steps are performed only when the logout is initiated by an explicit user action.
They are not performed when the logout is a consequence of a timeout.
3. WebSphere Application Server logout. The user’s credential token is marked as invalid,
and a respective cookie invalidation command is added to the response.
4. Browser redirect (302). The browser is redirected to render the post-logout target.
In the case of an authentication proxy, WebSphere Portal needs to be set up to redirect after logout
to the authentication proxy’s logout page. This way the authentication proxy is also notified of the
logout. If a user does not logout explicitly, the proxy cannot be notified of the portal session timeout
and the proxy session will time out eventually as well.
3.8 Customizing the portal login and logout processes
WebSphere Portal lets you customize the portal login and logout procedures at various places. The
following modifications are possible [10]:
•
Specifying the post-login and the post-logout redirection policy and targets.
•
Adding custom JAAS login modules that are used to authenticate a user and/or populate the
portals user JAAS Subject with principals or credentials.
•
Securing the login interactions and/or the personalized portal pages using SSL.
•
Extending the portal login and logout action classes.
4 Single sign-on (SSO)
WebSphere Portal is often used to integrate other enterprise information systems, and to present
them through the portal user interface. The recommended approach is that those systems do not
relinquish control of their application security, even if they are accessed through WebSphere Portal.
Therefore, the back-end systems continue to do their own authentication and authorization.
However, most implementations want to avoid requiring the user to repeatedly authenticate. This is
where SSO comes into play.
The goal of SSO is to provide a secure method of authenticating a user one time within an
environment, and to use that single authentication (for the duration of the session) as a basis for
access to other applications, systems, and networks.
In the context of WebSphere Portal, there are two SSO realms:
•
•
From the client to portal and other Web applications
From the portal to the back-end applications.
Those two realms are indicated in by loops.
Page 19 of 50
WebSphere Portal 6.0 Security, Version 6.0.0
Figure 11: Portal single sign-on realms
With single sign-on from the client to the Web applications and the portal, a client logs into one
Web application (once), and can then access all other Web applications that are part of the same
SSO realm, without receiving a second authentication challenge. It makes no difference whether
WebSphere Portal, or one of the other trusted Web applications, is the authenticating Web
application.
Single sign-on from the portal to the back-end applications enables a portal client to log into the
portal once, and then to access a number of back-end applications through respective portlets,
without having to authenticate at each of these applications.
4.1 SSO from the client to Web applications
You can provide SSO from the client to Web applications and the portal through these various
mechanisms:
0. LTPA support built into WebSphere Application Server (see Requests in a session which is
already authenticated)
1. Authentication proxy SSO support (for example WebSEAL, Netegrity SiteMinder, RSA
Cleartrust, or Entrust GetAccess)
The functional principle of these single sign-on solutions is essentially the same. Upon successful
authentication the client gets a security token that enables it to prove successful authentication and
to pass through subsequent requests without repeating the authentication.
Important: WebSphere Portal does not use any persistent cookies; it only uses cookies which are
deleted when the browser session is terminated. Sometimes persistent cookies are used to achieve
the goal of single sign-on. Persistent cookies are stored by the browser on the client in a form,
which has very little protection from reading and copying. This security concern is the major reason
to completely avoid the use of persistent cookies in WebSphere Portal.
4.1.1 SSO between Windows workstations and the portal
With Tivoli Access Manager for e-business Version 4.1 and later, you can implement SSO between
a Windows workstation and WebSphere Portal. That is, a user can log on to a local workstation and
use Windows® Internet Explorer to access the portal without needing to authenticate at the portal
again. This scenario requires that the user have an SPNEGO-enabled Web browser (such as
Microsoft Internet Explorer); it also requires Microsoft's IIS as the Web server for the portal along
Page 20 of 50
WebSphere Portal 6.0 Security, Version 6.0.0
with the Tivoli Access Manager Web server plug-in for IIS. You would configure it so that an eCommunity is established between the IIS plug-in and WebSEAL.
4.2 Portal-to-back-end SSO
Some back-end systems can be accessed using standardized technologies, such as J2EE
technologies (for example, Application Server Data Sources or J2C adapters) or Web services. If
portlets need to interoperate with one of these back-end systems and do not need any
sophisticated principal mapping mechanisms, it is recommended that you use these technologies.
For communication with other back-end systems that require proprietary or non-J2EE protocols,
WebSphere Portal offers a Credential Vault as a portlet service. This service provides portlets (and
the portal, for that matter) with a mechanism for mapping from a user identity (usually a user ID,
which is generally called a Principal) to another user identity and (usually) a credential, such as a
password, for that user ID.
Portlets should not store user credentials as part of their user-specific portlet data. Storing
credentials in the portlet data is not a recommended way of achieving single sign-on because
portlet data is stored in places that are insecure for storing user credentials; for example, in the
database where it could be read by any database administrator. Instead, convert these portlets so
that they use the Credential Vault.
Figure 12 illustrates the structure of the Credential Vault. Credentials are stored in Credential Slots,
through which user secrets are retrieved, created, modified, and deleted.
Figure 12: Credential Vault
Credential slots are contained in vault segments. A segment can be managed by both users and
administrators, or by administrators only. The vault segments map onto a specific vault
implementation through corresponding vault adapters.
4.2.1 How the Credential Vault works
WebSphere Portal’s Credential Vault works as follows:
•
The portal administrator can partition the vault into several vault segments.
Only portal administrators can create and configure vault segments.
Page 21 of 50
WebSphere Portal 6.0 Security, Version 6.0.0
•
A vault segment contains one or more credential slots, which are the “drawers” where
credentials are stored, and later retrieved, by portlets. Each slot holds one credential if user
defined, and one credential per user if defined by the administrator.
•
A credential slot is linked to a resource in a vault implementation, the place where the
credential secrets are actually stored. Examples of vault implementations are WebSphere
Portal’s default database vault and IBM Tivoli Access Manager’s repository.
A flag for each vault segment indicates if it is to be managed by the administrator or by the user.
Only administrators can create credential slots in an administrator-managed vault segment. Portlets
(acting on behalf of a portal user) are permitted to create credential slots only in user-managed
vault segments, but they can set and retrieve credentials in both types of segments.
Therefore, portlets that need a credential to complete their service have two options:
1. Use an existing credential slot that has been defined by the portal administrator in an
administrator-managed vault segment.
2. Create a new credential slot in a user-managed vault segment.
As a current limitation, WebSphere Portal installs one pre-configured user-managed vault segment
and does not permit the definition of any additional user-managed segments. Administratormanaged vault segments can be created without any limitation.
WebSphere Portal’s Credential Vault defines four types of credential slots:
•
Vault Slots in administrator-managed vault segments:
o A system slot stores system credentials where the actual secret is shared among all
users and portlets. It is a shared slot that belongs to an administrative segment.
o An administrative slot allows each user to store a secret for an administrator-defined
resource (for example, Lotus Notes). It is an unshared slot that belongs to an
administrative segment.
•
Vault Slots in user-managed vault segments:
o A shared user slot stores user credentials that are shared among the user's portlets. It is
a shared slot that belongs to the user segment.
o A portlet private slot stores user credentials that are not shared among the user's portlets.
It is an unshared slot that belongs to the user segment.
Details both on the administration of WebSphere Portal's Credential Vault and the corresponding
programming model for portlets can be found in [10].
4.2.2 Passive and active credential objects
The Credential Vault Service returns credentials in the form of credential objects. WebSphere
Portal differentiates between two basic types: passive and active credential objects.
Passive credential objects are simply a container for the credential's secret. Portlets that use
passive credentials need to extract the secret out of the credential. With passive credentials the
portlets are responsible for the authentication communication with the back-end. Listing 1 shows
how a portlet uses a passive credential that carries a user ID and password.
Page 22 of 50
WebSphere Portal 6.0 Security, Version 6.0.0
Listing 1. Passive credential object use (pseudo code)
// 1. Retrieve the credential object from the credential vault
UserPasswordPassiveCredential credential = (UserPasswordPassiveCredential)
service.getCredential(slotId, "UserPasswordPassive", null, porletRequest);
// 2. Extract the actual secret out of the credential object
UserPasswordCredentialSecret secret = credential.getUserSecret([…]);
// 3. Portlet connects to back-end system authenticates using the user's secret.
...
// 4. Portlet uses the connection to communicate with the back-end application.
...
// 5. Portlet takes care of logging of at the back-end.
...
An active credential object hides the credential's secret from the portlet; there is no method to
extract the secret. Instead, active credential objects offer methods that take care of the
authentication with the back-end system. They let portlets trigger authentication to remote servers
using standard mechanisms such as basic auth, HTTP form-based authentication, or POP3
authentication, without knowing the credential secrets. The portlets can ask the credential to
authenticate on their behalf, and then use the authenticated connection.
With active credentials the portlets never get in touch with the credential secrets; therefore, there is
no risk a portlet could violate any security rules. While there might not always be an appropriate
active credential class available, it is the recommended type of credential object to use. In addition,
for accessing server side credentials, the active credentials are attractive because they enable use
of crypto hardware that does not expose their secrets. Such crypto hardware5 only enables using
credentials inside the hardware with the supported authentication algorithms.
Listing 2 shows how a portlet uses an active credential; in this case, an active credential for HTTP
form-based authentication. The flow is illustrated in Figure 13, where the numbering coincides with
the numbering in Listing 2.
Listing 2. Active credential object use (pseudo code)
// 1. Retrieve the credential object from the credential vault
HttpFormBasedAuthCredential credential = (HttpFormBasedAuthCredential)
service.getCredential(slotId, "HttpFormBasedAuth", config, request);
// 2. Log into the back-end system
credential.login();
// 3. Get an authenticated connection to work with
URLConnection connection = credential.getAuthenticatedConnection();
// 4. Portlet uses the connection to communicate with the back-end application
...
// 5. Log out of back-end system
credential.logout();
5
IBM has a cryptographic coprocessor (IBM 4758PCI) for storing the private key and executing the
cryptographic functions. This module meets the FIPS PUB 140-1 level 4 specification. The card can keep the
server’s private keys secure (any data tampering will be recognizable) and can execute encryption algorithms.
Therefore, the private keys do not need to leave the card, and execution will be faster.
Page 23 of 50
WebSphere Portal 6.0 Security, Version 6.0.0
1a. Retrieve
Credential
Portlet API
Figure 13: Portlet using an active credential object for back-end SSO
Portlet
4. Send Business Request
2a. login()
3. Get Authenticated
Connection
Back-end System
2b. Authenticate
Active
Credential
Portal Engine
Credential Vault
Portlet Service
1b. Retrieve Secret
Vault Store
All credential types that are available within the portal are registered in a Credential Type Registry.
WebSphere Portal provides a small set of credential types “out of the box”, but additional credential
objects can easily be registered in this registry.
The credential classes that are included with the WebSphere Portal V6.0 are:
Passive credential objects:
•
SimplePassive - Stores secrets in the form of serializable Java™ objects. This can only be
done programmatically; the vault administration GUI does not currently support BLOB secrets
(which are needed in order to store serialized Java Objects).
•
UserPasswordPassive - Stores secrets in the form of user ID/password pairs.
•
JaasSubjectPassive - Stores secrets in the form of javax.security.auth.Subject
objects. It provides portlets with the JAAS Subject that the portal has established for the
user.
•
BinaryPassive - Simple standard implementation of PassiveCredential for binary credential
secrets. Stores secrets in the form of a byte array.
Active credential objects:
•
HttpBasicAuth - Stores user ID/password secrets and provides support for HTTP basic
authentication.
•
HttpFormBasedAuth - Stores user ID/password secrets and provides support for HTTP formbased authentication.
•
JavaMail - Stores user ID/password pairs and leverages the authentication functionality of the
javax.mail API.
•
LtpaToken - Supports authentication at a back-end system that is within the same Application
Server SSO-Domain as the portal.
•
SiteMinderToken - Supports accessing back-end systems that are in the same SiteMinder
SSO-Domain as the portal. It is typically used when a SiteMinder authentication proxy
protects the portal and other resources.
Page 24 of 50
WebSphere Portal 6.0 Security, Version 6.0.0
•
WebSEALToken - Supports accessing back-end systems that are in the same WebSEAL
SSO-Domain as the portal. It is typically used when a WebSEAL authentication proxy
protects the portal and other resources.
Credential objects do not implement java.io.Serializable and can, therefore, only be stored
in the portlet session as a transient value. This implementation is for security reasons; the
credential classes store the credential secret as private attributes. If they were serialized into the
Application Server session table, then the secret could potentially be read by anyone who has
access to this database.
5 Securing client-to-portal communication
Secure Sockets Layer (SSL) and its successor Transport Layer Security (TLS) are protocols that
leverage a variety of cryptographic algorithms to implement security, for example authentication
with certificates, session key exchange algorithms, encryption, and integrity checks. They are
common protocols that are often used to provide privacy and trust between communicating
applications such as Web clients and Web servers. When HTTP is used over such a secure
connection, this is known as HTTPS. SSL and TLS provide connection security with three basic
properties:
1. Confidentiality - Encryption is used after an initial handshake to define a secret key.
Symmetric cryptography is used for data encryption (for example, DES, RC4)
2. Authentication - The peer's identity can be authenticated using public key cryptography
(for example, RSA, DSS).
3. Integrity - Message transport includes a message integrity check using a keyed Message
Authentication Code (MAC). Secure hash functions (for example, SHA, MD5) are used for
MAC computations.
While TLS is the standard implementation, SSL still is more widely distributed. In this description,
we refer to SSL, but also imply TLS. WebSphere Portal is tested and supported to run with the
FIPS 140-2 compliant TLS providers available in WebSphere Application Server.
IPSec is a technology that can be used as an alternative to SSL (see Protected communication). It
works on a lower layer of the OSI reference model than SSL and is usually configured and handled
on the operating system level. Although the operating systems of most clients support IPSec today,
only a few have it already configured. Therefore, we do not recommend using it for the
communication between clients and the server complex.
When the communication between servers needs to be protected however, it is a question of
design whether to use SSL or IPSec. Both technologies offer advantages: IPSec is on the network
level and is, therefore, transparent to applications; they do not have to do anything to support it. In
addition, it might perform faster if the OS makes use of available crypto hardware6. SSL, on the
other hand, is widely supported and administrators have gained a lot of experience and confidence
with this technology over the years.
WebSphere Portal can be configured to support SSL [11]. For example, it can generate respective
URLs if needed; you can specify the protocol as well as the port.
The main questions with using transport or network layer security are where to terminate the
protected connections and which communication to protect. If a higher level of security is desired, it
is necessary not only to protect the communication across unprotected networks (such as the
Internet), but also the communication within the corporate networks. The threats of human errors
that might open up holes in the network protection as well as the threats of internal attackers (such
as disgruntled or dishonest employees) are not to be underestimated. In fact it is estimated that in
about half of the cases, these are the causes of security incidents.
6
SSL could exploit crypto hardware as well, but each application would have to support this.
Page 25 of 50
WebSphere Portal 6.0 Security, Version 6.0.0
Figure 14 shows how transport layer security would be implemented in the simplest of our
deployment scenarios (see Figure 2). The clients connect directly to the portal server; therefore, the
connection is secured with SSL.
Page 26 of 50
WebSphere Portal 6.0 Security, Version 6.0.0
Figure 14: Communication security for portal installations within a protected network
The second of our deployment scenarios (Figure 3) separates the Web server from the portal
server with firewalls between the client and Web server, and between the Web server and portal
server. Figure 15 shows one SSL connection between the client and Web server, and a second
one from the Web server through the firewall to the portal server.
Figure 15: Communication security for a portal installation in a trusted intranet
The third of the deployment scenarios (Figure 4) places a reverse proxy for authentication in the
DMZ and, behind another firewall, a cluster of portal servers that are fed by a load balancer7. A
possible secure communication implementation for this case could use SSL from client to reverse
proxy, and IPSec for the remaining path between the servers: one IPSec connection from
authentication proxy to the load balancer, and another one from load balancer to the portal cluster
as shown in Figure 16.
Figure 16: Communication security for a straightforward Internet portal cluster
In a fully clustered portal environment, with full transport layer security, the client’s SSL connection
is tunneled through the first load balancer and terminated at the authentication proxy cluster. The
7
When the authentication proxy is Tivoli Access Manager for e-business, no extra load balancer is needed
because load balancing capabilities are already built into this authentication proxy. The same applies if IBM
Edge Server is used together with Tivoli Access Manager Plugin for Edge Server.
Page 27 of 50
WebSphere Portal 6.0 Security, Version 6.0.0
tunneling can be done because the first load balancer does not need to read the request’s content
for its load balancing strategy. That is only needed for more sophisticated strategies such as
session affinity, for example, when all requests by the same user are always routed to the same
cluster machine. The second load balancer will usually use such a strategy; therefore, the next SSL
connection needs to be terminated at this server.
Finally, there is a third SSL connection between load balancer and portal cluster. For this scenario,
we have shown how to connect to an LDAP directory. The communication between application
server and LDAP server is protected as well because the LDAP queries and responses might
contain confidential data. You can configure WebSphere Application Server’s security component
to use LDAPS (LDAP over SSL)
Figure 17: Communication security implementation in a fully clustered portal setup
5.1 Restricting the protection to sensitive communication only
Using SSL is not cheap; it costs a considerable amount of computing power. The most expensive
SSL operation is the initial handshake, but the symmetric encryption of the bulk data produces
additional load. Therefore, limit the SSL protection to the necessary minimum. WebSphere Portal
can switch between SSL and non-SSL connections during a session. You can set up SSL for the
portal with these configurations:
• For the user login interaction only
• For login and the part of the portal that is restricted to authenticated users
• For the whole portal
The final decision to whether a portal should protect none, all, or only parts of its communication
with SSL should be based on the sensitivity of the data.
5.2 Using client certificates
The SSL and TLS protocols specify the authentication of the communication partners through the
use of X.509 certificates. The client can use a certificate to authenticate to the server. This
authentication through the client certificate is more convenient than typing a password and also
avoids the known security drawbacks of passwords. In addition, if the private key that is associated
with the client certificate is stored on a smart card, then this form of authentication can establish
particularly strong trust.
The decision to enforce certificate-based client authentication is a configuration option with
WebSphere Application Server. If an authentication proxy such as Tivoli Access Manager’s
WebSEAL is used, then select this setting in the WebSEAL configuration.
Page 28 of 50
WebSphere Portal 6.0 Security, Version 6.0.0
6 Securing back-end connections
Some portlets are designed to access back-end applications that house important enterprise data.
You have these two options to secure back-end data:
1. Selected portlets can use SSL connections to exchange data with a corresponding back-end
application. Depending on the back-end application, an SSL handshake with client
authentication can be required.
2. The portal and the back-end applications can establish a virtual private network, for example,
using IPSec.
6.1 Using IPSec between the portal and back-end applications
Using IPSec for back-end connections is an alternative to using SSL (see Securing client-to-portal
communication for a more detailed explanation of these two technologies). The fact that IPSec is
efficiently operating on the network layer and that it is easy to configure in most current operating
systems makes it worth considering in this context.
7 Controlling access to portal resources
Authorization is based on authentication. In order to enforce that only authorized subjects (users)
are allowed access to the portal, it must be assured who the subject is. Authentication is, therefore,
the first step performed on each request coming into the portal server.
Portal Access Control (PAC) defines the set of sensitive operations a specific user is allowed to
execute within the portal resource space. This set of operations is defined by the set of permissions
granted to the user. WebSphere Portal uses the role concept to enable convenient management of
permissions based on the job responsibilities of individual users. A role can be considered a
container of permissions that comprises all authorizations necessary to act in a specific role on a
specific part of the protected resource hierarchy. Assigning a role to a user grants all the contained
permissions in the role to the user.
Access control administration can be performed using the portal administration portlets,
XmlAccess, or the portal scripting interface.
7.1 Access control concepts
First, we define key terminology and concepts involved in WebSphere Portal's access control
capabilities.
7.1.1 Sensitive operations
Users (or more general clients) interact with the portal in a multitude of ways ranging from simple
page view requests to complex update operations like cloning an installed portlet. Access to almost
all of those operations has to be restricted to a set of authorized users. Therefore, all sensitive
operations are protected by the portal access control component.
A well defined WebSphere Portal access control policy (see InfoCenter [12]) maps each sensitive
operation to a specific set of permissions that are required to be allowed this operation. Access
control administration then defines each user’s permissions by creating and deleting the
corresponding roles and role assignments.
7.1.2 Protected resources
Those resources within the portal object model that require access control protection are referred to
as protected resources. All protected resources are linked into tree structures that reflect their
internal topology. For example, while individual sub pages are linked as child resources of their
Page 29 of 50
WebSphere Portal 6.0 Security, Version 6.0.0
containing parent pages, individual portlet definitions are linked as child resources of their
enclosing portlet applications. Figure 18 depicts a schematic overview of these resources within the
portal release data domain.
Figure 18: Protected resource hierarchy within the portal release database domain
The vast majority of the resources within this hierarchy represent portal resource instances that
require access control protection (such as individual portal pages or portlets); but some of them are
special virtual resources. Figure 18 shows the fixed set of supported virtual resources as grey
boxes and the resource instances as blue boxes.
Virtual resources are used in two ways:
1. They guard sensitive operations that do not affect specific resource instances as such but the
whole portal or a whole portal concept. For example, the virtual resource XmlAccess is used to
protect the ability to use the XmlAccess configuration tool.
2. They group resources of the same or related resource types. For example, the virtual resource
Content Nodes is the root node of all pages (resource instances of resource type Content
Node) within the portal page hierarchy.
7.1.3 Roles and role types
A role is a set of permissions on individual protected resources. If a user shall be allowed to
execute a specific sensitive operation, she needs to have corresponding role assignments
Page 30 of 50
WebSphere Portal 6.0 Security, Version 6.0.0
providing the required permissions on the affected resources. Role assignments can be either
explicit (a user or user group is directly assigned to a role) or implicit (the user or user group is a
member of a user group that has a corresponding explicit role assignment). The set of permissions
granted to a specific user is defined by the union of all permissions contained in all explicitly and
implicitly assigned roles of this user.
Roles within WebSphere portal are typed, such that each role instance is of a specific role type.
WebSphere Portal supports the role types Administrator, Security Administrator, Delegator,
Manager, Editor, Contributor, Privileged User, and User. Role types model the different ways
people interact with the system depending on their job responsibility.
Role Type
Allows…
User
Viewing portal content (for example, viewing a specific page).
Privileged
User
Viewing portal content, personalizing portlets and pages, and creating new
private pages.
Contributor
Viewing portal content and creating new resources. The Contributor role type
does not include the permission to edit resources. It only allows you to create
new resources.
Editor
Creating new shared resources and configuring existing resources that are used
by multiple users.
Manager
Creating new shared resources as well as configuring and deleting existing
resources that are used by multiple users.
Security
Administrator
Creating and deleting role assignments for roles tied to specific resources.
Administrator
Unrestricted access to resources. This includes creation, configuration, and
deletion of shared resources. Administrators can also decide who shall have
access to the resources by creating and deleting corresponding role
assignments.
Delegator
Assigning specific users or user groups to those roles which the delegator holds
himself.
As illustrates, role types are organized in a hierarchy. Each role type extends the privileges
contained in the role types directly beneath it in the hierarchy. For example, Privileged Users and
Contributors can do everything that Users can do. Managers can do everything that Editors,
Contributors, and Users can do.
Page 31 of 50
WebSphere Portal 6.0 Security, Version 6.0.0
Figure 19: Role type hierarchy
7.1.4 Role assignment and inheritance
In addition to the role type, an individual role instance is also characterized by an additional
attribute called the domain root resource, which identifies the set of protected resources that are
affected by the given role instance. By default, the role affects all resources contained in the
subtree of protected resources rooted at the domain root resource. As a convention, a given role is
referred to by concatenating the role’s type and the name of the domain root resource, separated
by the “@” sign (that is, <role type>@<domain root resource>).
For example, the role Editor@Market News Page refers to a role of type Editor tied to a specific
page in the portal page hierarchy named Market News Page (see ). The permissions in such a role
allow executing sensitive operations on the Market News Page that correspond to the job
responsibility of an Editor or any other less privileged role in the role type hierarchy (see ).
Through inheritance, a specific role contains permissions for accessing the domain root resource,
and it also contains corresponding permissions on all resources in the subtree rooted at the domain
root resource. In the previous example, users having a role assignment to the Editor@Market
News Page role are also allowed to act in the Editor role on the USA Market News Page (see ).
Figure 20: Page hierarchy example
If inheritance is not intended, the inheritance can be blocked as described in the next section.
Page 32 of 50
WebSphere Portal 6.0 Security, Version 6.0.0
7.1.5 Role blocks
You might want to prevent a specific role from affecting all resources below the role’s root resource
in the resource hierarchy. In this case, you can control the inheritance behavior of some or all of
those resources and prevent them from being affected by this role. For example, in , there is a role
block for roles of type Editor inserted above the Europe Market News Page. This prevents the
Europe Market News Page from being affected by other roles of type Editor that may exist at
resources above this page.
This example illustrates that a role block is role type-specific and is tied to a specific resource. A
specific role block disables inheritance on the corresponding resource for all roles of the
corresponding role type. The block for roles of type Editor above the Europe Market News Page
does not block roles of types different from Editor (such as Manager or User roles). You could
block these roles separately using corresponding role blocks, if desired. Roles of type
Administrator or Security Administrator can only be blocked using XmlAccess. If Administrator
and/or Security Administrator role are blocked, XmlAccess will block all other role types as well.
Access control supports two kinds of role blocks called inheritance blocks and propagation blocks.
While inheritance blocks shield a resource from inheriting from their parent resources (like the one
depicted in ), propagation blocks inhibit inheritance from the resource to its child resources. You
could think of this as blocking above the resource (inheritance block) or blocking below a resource
(propagation block).
7.1.6 Resource ownership
Each resource protected by portal access control can (but need not) have a dedicated owner.
When a user creates a new portal resource (for example, a new page) the executing user
automatically becomes the initial owner of that resource. Being owner of a resource provides
specific permissions on that resource including the right to delete the resource. Ownership provides
the same permissions on the owned resource as being in the Manager role on the resource. The
ownership property of a resource is not subject to inheritance. Ownership can be changed, so it is
possible to assign a specific resource a new owner, giving this user the corresponding privileges on
that resource. For non-private resources, the ownership can also be removed.
7.1.7 Private pages
Portal access control supports the notion of private pages. A private page can be accessed only by
the owner of the page. Privileged Users on a non-private page (users having a Privileged User
role assignment for that page) are allowed to personalize this page. Personalizing a non-private
portal page results in the creation of a private personalized copy of the corresponding page (by
implicit page derivation). All modifications the Privileged User does to this page are only
accessible to this user because it is now a private version of the page.
7.1.8 Resource domains
WebSphere Portal Version 6 introduced the notion of four distinct database domains called
Release, Community, Customization, and JCR domain. Those database domains can be
represented by individual database schema within the same database instance or by separate,
distinct database instances. The four domains contain different kinds of data:
•
The Release database domain contains all portal configuration data that make up a portal
installation in a specific version (or release) such as the portal page topology and the
configuration data for individual portlets.
•
The Customization domain contains private user customization data such as implicitly derived
pages or user specific portlet preferences.
•
The Community domain contains those pages and portlets that are used in the Composite
Application Infrastructure (introduced with WebSphere Portal V6.0).
Page 33 of 50
WebSphere Portal 6.0 Security, Version 6.0.0
•
The JCR domain contains those portal resources that are stored within the Java Content
Repository (JCR) such as documents, folders, policies, and templates
Resources in any of these database domains may require access control protection and are,
therefore, considered protected resources. The access control configuration data for any protected
resource is stored in the same database domain as the resource itself. This allows maintaining a
consistent access control configuration when you backup individual database domains.
The subset of the protected object space that is stored within the Release domain is depicted by
Figure 18. Figure 21 depicts the protected object space as it exists in the Java Content Repository
(JCR) domain in WebSphere Portal.
Figure 21: The protected resource hierarchy of the JCR domain
Portal access control protects the following types of resources stored in the Release domain:
• Web modules
• Portlet applications
• Portlets
• Content nodes (this type includes pages, labels, and externals URLs)
• URL mapping contexts
• WSRP producers
• PSE sources
• User groups
• Users (not protected individually, but through the groups to which they belong)
Portal access control protects the following types of resources stored in the JCR domain:
• Document Libraries
• Documents and folders
• Template root, template categories, and templates
• Policy root and policies
• Personalization rules
Page 34 of 50
WebSphere Portal 6.0 Security, Version 6.0.0
7.2 Delegating access control administration
Portal access control supports the concept of delegated administration. In the context of access
control, the term administrator is generally applied to users that are allowed to change access
control configuration (for example, create role assignments). Delegated administration means that
an administrator can delegate specific subsets of his or her administrative privileges to other users
or user groups. The receivers of these privileges become sub-administrators, which, in turn, can
delegate subsets of their privileges to some sub-sub-administrators and so on.
Portal access defines a delegated administration policy (a subset of the WebSphere Portal access
control policy described in the InfoCenter [12]) that controls which permissions are necessary to be
allowed to do a specific change to the access control configuration (for example, to create a
specific role assignment). This policy allows restricting administrative privileges to specific parts of
the protected resource hierarchy and to specific user groups. Therefore, you can establish subadministrators that control role assignments for a specific subtree of the resource hierarchy (for
example, nested pages) and a specific set of user groups.
The administrative user and group that are created or identified during portal installation are initially
set as the domain administrative user or group for each resource domain. These users and groups
are implicitly assigned the Administrator role at the root resource of the protected resource
hierarchy in the corresponding resource domain. This role implies full access to all shared
resources in the domain. You can define the administrative users and groups separately for each
domain by changing settings of a Portal Service (see the WebSphere Portal InfoCenter [12] for
details); therefore, you could set different administrative users or groups for each resource domain.
7.3 Access control in the composite application infrastructure
(CAI)
The concept of composite applications is a key element within the IBM's SOA strategy. A
composite application aggregates one or more business components into a single, coherent entity.
The individual business components and the interactions among them can implement sophisticated
business logic to serve a meaningful purpose for business users.
WebSphere Portal V6.0 introduced the composite application infrastructure (CAI) that provides the
runtime environment and the programming model for such applications. You can plug existing
software components (for example, EJBs, J2C Connectors, or other software services) into this
infrastructure by implementing corresponding adapter code to mediate between the CAI and the
business logic contained in the components.
In WebSphere Portal, you can define composite applications in a declarative fashion using
application templates. A template defines the internal structure of the application including
references to the business components it contains, meta-data associated with those components,
and the user interface which is composed of portal artifacts such as portlets and pages.
The template also defines the access control structure for the application by defining the set of
application roles that are exposed by the application. An individual application role represents a set
of application-specific privileges on the business logic level (that is, independent of the access
control details that may exist on the business component level).
For example, a banking application may expose application roles such as Customer, Teller, and
Supervisor. A team room application may expose roles such as Guest and Contributor. The
individual application roles are than mapped to individual roles exposed by the business
components inside the application (see Figure 22). If the application contains portal artifacts such
as portlets and pages, you can map individual application roles to portal roles to affect those
resources using the portal role types introduced in Section 7.1.3, Roles and role types.
As depicted in Figure 22, the Teller role in a Banking example could map to some Operator role
defined by an ACMEBanking business component, and, at the same time, to a portal role of type
Privileged User on the Teller portlet. If a user is assigned to this application role, the CAI
Page 35 of 50
WebSphere Portal 6.0 Security, Version 6.0.0
propagates this update information to the ACMEBanking component through a corresponding life
cycle interface (the Membership interface in this case The CAI also insures that this user
automatically has Privileged User permissions on the Teller portlet.
Figure 22: Application roles and membership
As discussed in Section 7.1.8 Resource domains, all resources that belong to the CAI are stored
exclusively within the Community database domain and are managed through the corresponding
administration portlets.
•
The Membership portlet lets you manage membership information; that is, the mapping
between users and application roles.
•
The Roles portlet lets you manage the role mapping information; that is, the mapping between
application roles and component roles (see Figure 22)
For a comprehensive introduction to the portal composite application infrastructure can be found
see [13].
7.4 Integrating external authorization systems
There are a number of systems in the market that are dedicated to controlling access to IT
resources and applications. Sometimes these dedicated systems are called “3A systems”, because
they offer centralized Authentication, Authorization and Administration. Examples are Tivoli Access
Manager for e-Business, Netegrity’s SiteMinder, and Entrust’s GetAccess. You can set up the
access control system of WebSphere Portal to let external 3A systems control portal resources.
WebSphere Portal ships with authorization adapters for Tivoli Access Manager for e-Business and
for Netegrity SiteMinder.
Portal access control lets you put individual subtrees of the protected resource hierarchy under
external protection. For example, using the Resource Permissions portlet, you can select a
resource and change its externalization state. As a result, the selected resource and all resources
contained in the subtree rooted at this resource are either put under external access control or
brought back in to be protected by portal internal access control depending on the specific
externalization state chosen. Inheritance always stops between resources that have different
externalization state (this also applies to Administrator and Security Administrator roles). This
Page 36 of 50
WebSphere Portal 6.0 Security, Version 6.0.0
guarantees that each resource is either exclusively protected by portal access control or by the
external system.
Putting resources under external protection does not mean that the resource information as such is
added to the protected object space of the external system. Only the roles that exist on those
resources are registered there. An administrator of the external system can create role mappings
for these roles, typically by assigning corresponding access control lists to the roles. The roles and
role blocks are exclusively controlled by the portal. Only the mapping between roles and
users/groups is managed through the external authorization system.
Changing the externalization status of resources is considered a sensitive operation and requires at
least Security Administrator@Portal and Security Administrator@External Access Control
authority. External Access Control is a virtual resource that guards the concept of externalizing and
internalizing resources. This resource is put under external protection during portal installation and
cannot be internalized. This approach guarantees that the external security administrator cannot be
overruled by a portal security administrator.
7.5 Administering access control
You can administer access control for resources stored in the Release or JCR domain using the
Resource Permissions and User and Groups Permissions portlets.
•
The Resource Permissions Portlet lets the administrator navigate through the protected
resource hierarchy, and provides a resource centric view of the configuration. For example,
"Are there role blocks defined on the selected resource?", "Which user groups are considered
to be the Editor of this resource?" It also allows updating the configuration, so it let’s you
create/delete role assignments, create/delete role blocks, change the ownership of the
resource and change the externalization status of the resource if an external authorization
provider is installed.
In the case of managing access control on folders and documents, the navigation part is done
using dedicated UIs, for example, the PDM portlet.
•
The User and Groups Permissions Portlet lets the administrator first select a specific user or
user groups, and provides a user/groups centric view on the access control configuration. It
supports the same set of actions as the Resource Permissions Portlet.
Resources from the Community domain are exclusively administered through the new Roles and
Membership portlets of the CAI.
•
The Membership Portlet is used in the context of a specific application. A user with
membership management privileges within the given application can assign individual
application roles exposed by that application to individual users and groups.
•
Like the Membership Portlet, the Roles Portlet is used within the context of a specific
application. A user with application manager privileges within the current application can map
individual application roles exposed by the current application to individual roles exposed by
the individual business components that are comprised within the application.
In addition to these portlets, the XmlAccess configuration tool and portal scripting can be used to
administer access control for resources stored within the release domain. There are no access
control administration facilities for resources stored in the customization domain because this
domain contains only private resources that can only be accessed by the corresponding resource
owner.
Page 37 of 50
WebSphere Portal 6.0 Security, Version 6.0.0
7.5.1 Administering access control using the XML Configuration
Interface
The XML Configuration Interface (also referred to as just XmlAccess) supports all aspects of Portal
Access Control; that is, role assignments, role blocks, ownership, and externalization state. The
access control information of individual resources modeled in XmlAccess is contained in the
<access-control> sub-element. You can use this element to define the initial access control
configuration for resources that are created using XmlAccess, or you can update the access control
information for existing resources (for example, by exporting the configuration of a page,
manipulating the access-control sub-element, and re-importing the configuration of the page into
the portal).
The access-control element only contains the explicitly defined access control data; that is, it does
not contain implicitly assigned roles or inherited roles. For example, in the little scenario depicted in
the access-control element of the Market News Page would contain the role assignment
information for Bob; the one for the Europe Market News Page would contain the inheritance block
of type Editor; and the access-control element of the USA Market News Page would be empty. In
other words, Bob’s inherited role assignment on the USA Market News Page is not visible in the
access-control element of that page. Instead, it is implicitly given by the fact that Bob has a noninherited role assignment to parent page and the lack of role blocks between those two pages.
The following sample shows you how to block inheritance on a specific page by inserting role
blocks and than explicitly assign rights to this page. The XML fragment given below first identifies
the page to be updated via its unique name ibm.portal.SamplePage.2. It then adds two inheritance
blocks on this page for role types Manager and Editor. As a result, this page is no longer affected
by roles of this type that may exist at parent resources of the ibm.portal.SamplePage.2 page. The
new Manager and User role assignments that take effect starting with this page are created with
the succeeding role and mapping elements.
<content-node action="update" uniquename="ibm.portal.SamplePage.2">
<access-control>
<!-- The manager role should not be inherited
automatically from parents of this page. -->
<role-block type="inheritance" actionset="Manager"/>
<role-block type="inheritance" actionset="User"/>
<!-- The manager role is set explicitly on this page. -->
<role actionset="Manager" update="set">
<mapping subjectid="wpsadmin" subjecttype="USER"
update="set"/>
</role>
<role actionset="User" update="set">
<mapping subjectid="yourusername" subjecttype="USER"
update="set"/>
</role>
</access-control>
</content-node>
Role propagation blocks (see Section 7.1.5 Role blocks) can be inserted in the same way using a
type attribute of value 'propagation'. The type attribute can also be set to the value 'none' if there
shall be neither an inheritance nor propagation block on the resource (as shown in the following
example for roles of type User).
<role-block type="none" actionset="User"/>
XmlAccess can not only be used for managing access control for pages, it is also applicable for
web modules, portlet applications, portlets, user groups, URL mappings, WSRP producers, and
virtual resources like shown in the sample below.
Page 38 of 50
WebSphere Portal 6.0 Security, Version 6.0.0
<virtual-resource name="USER_GROUPS" action="update">
<access-control>
<role actionset="Administrator" update="set">
<mapping subjectid="wpsadmin" subjecttype="USER" update="set"/>
</role>
</access-control
</virtual-resource>
7.5.2 Administering by using Scripting
In addition to the XmlAccess framework, WebSphere Portal Server supports a second configuration
framework, the Portal Scripting interface. Portal Scripting differs from XmlAccess in the following
aspects:
•
Portal Scripting supports access control management only for pages, portlets, portlet
applications, and web modules.
•
Portal Scripting allows to write reusable scripts to modify access control configuration
As XmlAccess, the Scripting interface shows only explicit role assignments to the resources, so
neither implicit nor inherited role assignments can be queried using the Portal Scripting interface.
Portal Scripting uses the same model as the scripting interface supported by WebSphere
Application server. Thus, access to access control configuration data is done via MBeans. Two
beans are defined in the area of access control:
•
$Access – provides function to get and set Access Control objects and lists all available
role types
•
$PacList – keeps Access Control objects of the queried resource as well as information
on blocks and is used to store the targeted modifications
Let’s again take the ibm.portal.SamplePage.2 as an example. If we want to create the same
Access Control settings as shown in the XmlAccess sample, we will end up in a script similar to the
following:
#General part. Need to authenticate first
if { $argc != 2 } {
#UserId and Password are passed as cmd line parameter.
puts "invocation syntax: wpscript -f testme.jacl -profile mylogin.jacl
<user> <pwd>"
exit
}
set user [lindex $argv 0]
set pwd [lindex $argv 1]
$Portal login $user $pwd
#Get the PacList of the Content Node you want to change
$Content find page uniquename ibm.portal.SamplePage.2 select
$PacList edit [$Access getacl Content [$Content current]]
#Now modify the AccessControl setting
$PacList grant User name "uid=youruser,dc=users,o=myorg"
$PacList grant Manager name "uid=wpsadmin,dc=users,o=myorg"
$PacList block User inheritance
$PacList block Manager inheritance
Page 39 of 50
WebSphere Portal 6.0 Security, Version 6.0.0
#check if the List has been changed and write back if needed
if [$PacList modified numeric] {
$Access setacl [$PacList done]
}
#show the new active settings
$PacList view [$Access getacl Content [$Content current]]
#list all principals in all lists
foreach as [$Access listall actionsets] {
puts "\nPrincipals for $as:"
puts [$PacList list $as all]
}
The sample can be executed using the wpscript command line tool which is located at
wp_home/bin like the following:
wpscript.[sh|bat] -port port_number -f script_file_name.jacl <userid>
<password>
Let’s have more detailed look into the script shown above. First of all we have to authenticate at the
Portal Server instance to get the necessary right to perform those actions. Then the $PacList
object is filled with information from this call. Before that call accessing the $PacList object would
lead to an exception.
$PacList edit [$Access getacl Content [$Content current]]
Now modify the Access Control setting by either setting a block, removing a block, grant or revoke
access and in the end save and close the $PacList object by using
$Access setacl [$PacList done]
Another useful command, not shown in the sample, is to check if a block is set or not:
$PacList show <actionset> <flag> numeric
where actionset can be any of the defined Access Control role types in the system, flag can be
inheritance or propagation and the key word numeric lets you use this command within a
conditional statement. Note that the numeric value for 0 indicates a blocked and 1 stands for not
blocked.
7.6 Auditing
WebSphere Portal has a built-in auditing function that can be used to log certain events and their
originators into a separate log file. This file can then be used to track administrative activities. For
each event the timestamp, an optional transaction ID, the user performing the action, and individual
event details are logged.
Per default, the auditing function is completely disabled and can be enabled individually for each of
the following events by configuring the Audit Service [14]:
•
•
•
•
•
•
•
•
•
•
•
•
Creating, modifying and deleting users and groups
Creating, modifying and deleting portlet applications
Assigning and revoking roles to and from users
Modifying role blocks
Modifying resource ownership
Creating, modifying and deleting protected resources
Externalizing and internalizing resources
Installing and uninstalling web modules
Creating and deleting application roles
Assigning and revoking application roles to and from users
Adding and deleting roles to application roles
Initializing a database domain
Page 40 of 50
WebSphere Portal 6.0 Security, Version 6.0.0
8 Portlet security
8.1 Supporting Java 2 Platform Security
Java 2 Platform Security is a security feature that was newly introduced by WebSphere Application
Server Version 5. This feature enables protection of individual sensitive operations (such as file I/O
or network access) such that code must be granted certain permissions in order to be allowed to
execute those operations.
For example, if Java 2 Platform Security is enabled on the JVM, code that wants to open a
java.io.FileInputStream() object on a file, must be assigned a corresponding java.io.FilePermission.
Otherwise, the call will fail with a corresponding security exception being thrown by the Access
Controller built into the Java runtime system. A detailed discussion of the Java 2 Platform Security
model can be found in the Java2 Platform Security Architecture document [15].
The assignment of individual permissions to individual code sources is done using policy files. The
syntax and semantics of those files is defined by the Java Language Specification. WebSphere
Application Server uses a specific set of policy files to set up Java 2 Platform Security for code
running on the JVM of a WebSphere server instance. The installation procedure of WebSphere
Portal updates those policy files, granting all code shipping with WebSphere Portal full access to
system resources. Specifically, this is achieved by granting the
javax.security.AllPermission to the shared libraries used by portal using the server.policy
file, and to the individual portlets using corresponding was.policy files (see the WebSphere
Application Server InfoCenter for a complete discussion of all policy files used by WebSphere
Application Server).
All other code running within the WebSphere Portal environment runs with permissions granted
according to the WebSphere Java 2 Platform Security setup. By default, this matches the default
permission set for Web containers, as defined by the J2EE specification. If a portlet needs
additional permissions in order to operate correctly (for example, to write report data to the file
system), you can insert a was.policy file into the corresponding WAR archive file. You need to
place the was.policy file in the portletname.war/META-INF directory prior to packaging the
portlet.
In order to make WebSphere Application Server pick up the information contained in the
was.policy file, the was.policy file is automatically moved from the war/META-INF directory
to the ear/META-INF directory during portlet deployment. Therefore, in order to modify the
permissions of an installed portlet after it has been deployed, you must modify the was.policy file
within the ear/META-INF directory of the corresponding WebSphere nodes.
Portlets can use the public portlet API exposed by WebSphere portal including the portlet services
and the portal JSP Tag Library, without being granted additional permissions. Java 2 Platform
Security support is intended to provide an administrative means of controlling access to system
resources (for example, access to files or network facilities). However, enabling Java 2 Platform
Security does not completely prevent malicious portlet code from damaging the portal or reading
sensitive data available to the portal runtime (for example, by maliciously calling internal portal
APIs). Therefore, at this point in time, portlet developers are still responsible for making sure that
portlets keep sensitive data secure, and that they do not open up exposures that undermine the
overall portal security. The portal administrator is still responsible for only installing portlets that are
trusted enough.
Java 2 Platform Security can be enabled and disabled using the WebSphere administration
facilities. Java 2 Platform Security is orthogonal to J2EE security, so you can enable Java 2
Platform Security independently from enabling WebSphere Global Security.
Page 41 of 50
WebSphere Portal 6.0 Security, Version 6.0.0
8.2 Verifying secure connections
Some portlets will require secure connections; that is, they need the guarantee that the data that
they send is kept confidential. If the portal is enabled to serve pages via SSL, portlets can initiate
an SSL connection with a “start transaction” link. However, the portlet needs to check for each
request, whether the connection is still secure. This can be done with the request.isSecure()
method. If a request did not come over a secure connection, the portlet must not write confidential
data to the output stream (see also Restricting the protection to sensitive communication only)8.
8.3 Preventing cross-site scripting attacks
Because portlets can directly access the markup stream, they are exposed to Cross Site Scripting
attacks like any other Web application. Therefore, the portlet developer is responsible for properly
encoding all data prior to writing it to the markup stream. This is typically done using the JSTL out
tag from within JSPs or using the ResponseUtils class supported by WebSphere Application when
plain Java code is writing to the markup stream. Otherwise, if user provided data (such as a URL
parameters) are directly written to the markup stream, the receiver of that markup (the Web
browser) may parse this data as active content (JavaScript) and execute code on the client's
computer (for example, steal browser cookies).
In order to reduce the risk for such attacks, the portal engine can be configured to do some basic
filtering of portlet input, and converts the characters “less-than” and “greater-than” to the respective
HTML escape sequences; however, this filtering addresses only a subset of potential
vulnerabilities. Because it is a common problem, there is plenty of information on Cross Site
Scripting on the Web; for example, see [16].
A similar kind of problem arises when a portlet aggregates markup from a third-party server, for
example with a clipping portlet or by integrating remote portlets via WSRP.
8.4 Dangerous URL Protection
WebSphere Portal uses two basic types of URLs:
•
URLs that are purely navigational: so-called render URLs or render requests. They do not
cause changes to the persistently stored data, with the possible exception information about
the navigational state, if this is to be persisted for session failover.
Examples include links to pages in WebSphere Portal's navigation bar.
•
URLs that cause an action that might change persistent data: so-called action URLs or action
requests.
Examples are URLs used to create a new page or to delete a user. They are not dangerous per
se, but they should not be executed accidentally, without the user's knowledge.
The threat to be addressed is as follows: An attacker figures out the URL that causes a specific
change to the persisted portal configuration, for example to delete the portal root page. He can do
this, for example, by examining the corresponding page's HTML markup in his own portal
installation where he would be allowed actually allowed to delete the root page. He then sends this
URL to a high number of users of the target portal (he must first adjust the server part of the URL
accordingly), and use phishing techniques to make them follow the link (for example, by hiding the
link behind some faked “urgent update of you personal data required” message). If one user that
has been granted enough permissions in the target portal clicks on the link, the unintended
operation would be executed.
8
There remains one problem however: In a complex portal setup, the SSL connection will usually be
terminated at an earlier node, for example at the authentication proxy. In such a case, the isSecure()
method can not return the correct state (always “false”). The Web Container of the WebSphere Application
Server offers some special HTTP header field that can be used by an SSL offloader to indicate that the
incoming connection has been through SSL – the HttpsIndicatorHeader field. See the Web Container custom
properties section in the WebSpehre Application Info Center for detailed information on this field.
Page 42 of 50
WebSphere Portal 6.0 Security, Version 6.0.0
WebSphere Portal has a built-in functionality to avoid such a malicious execution of action URLs.
Each action URL is valid for one user only; namely, for the one who requested the page on which
the link is rendered. This is achieved by calculating specific hash values that are encoded into the
URL when the URL is created, and validated when URLs are to be executed. If the validation fails,
the action will not be executed. The hash value is based on both the action to be executed and the
user ID of the executing user.
9 WSRP Security
WebSphere Portal lets a portal consume portlets from remote Producer portals as Web services
which are based on the Web Services for Remote Portlets (WSRP) protocol [17]. These remote
portlets can be used like local portlets with some restrictions. This section describes several
security aspects that are important when using WSRP.
9.1 Securing connections to remote portlets
In the default mode, WSRP connections are not secured, and there is no reliable user identity
propagated from the Consumer portal to the Producer portal. Therefore, the portlet cannot rely on
having a user object with correct user information and/or credentials. Propagated user meta data
can be used to establish a personalized user experience (for example, to display weather
information based on the ZIP code in the user profile). However, this information should be
considered little more than a "hint" at the user's real identity and not an authenticated user identity.
WebSphere Portal's support for WSRP permits propagating authenticated user identity by
leveraging the Web Services Security runtime available in WebSphere Application Server. WSRP
connections can also leverage SSL to establish confidential communication channels and to
prevent man-in-the-middle attacks.
9.1.1 Securing WSRP services on the Web Service layer
9.1.1.1 WS-Security
WSRP is a Web Services standard on the top of the Web Services stack, whereas security aspects
are handled by lower layers, defined by the Web Services Security (WS-Security) specification [18].
WS-Security is an OASIS standard that forms the base for securing Web Services at the message
level. It provides a general-purpose mechanism for associating security tokens with messages; it
does not require any specific type of security token.
The WebSphere Portal WSRP implementation on both the Producer and Consumer sides runs in
the JSR 109 compliant Web container of WebSphere Application Server. It relies on the WSSecurity support available in the WebSphere Application Server Web Services runtime, including
the corresponding extension points, to establish the security context. WebSphere Portal always
bases reliable user identification (that is, the user identity that is used for access control
enforcement) on the security context established and managed by WebSphere. For this, a variety
of tokens are supported by WebSphere Application Server, including the LTPA token. In addition,
you can use extension points to integrate custom token formats. Because WebSphere Portal
WSRP is based on the WS-Security runtime of WebSphere Application Server, future extensions to
the WS-Security support in WebSphere Application Server will automatically be available to WSRP
as well. See the WebSphere Application Server Information Center [19] for more details on the WSSecurity support.
There is a limitation regarding the compatibility of WS-Security support in WSRP when using both
WebSphere Portal Version 5.x and Version 6.x in a mixed environment. The limitation relates to the
fact that assembly tools (which you use to import the portal EAR file in order to perform the WSSecurity configuration for WSRP) generate different WS-Security extensions and binding
configuration files based on the J2EE version. Because WebSphere Portal 5.x is a J2EE 1.3
application, the assembly tools create configuration files using WS-Security 1.0 draft 13.
However, WebSphere Portal version 6.x is a J2EE 1.4 application, so the files are created using
the final WS-Security 1.0 standard. After the configuration files are created, the corresponding
Page 43 of 50
WebSphere Portal 6.0 Security, Version 6.0.0
format is used independently of the WebSphere Application Server version on which the portals
run. Therefore, using WebSphere Portal V5.x and V6.x as mixed Producer and Consumer portals
will fail because the message formats are incompatible.
There are two potential solutions to overcome this limitation:
1. You could migrate the 5.x portal EAR to J2EE 1.4, and generate the configuration files again.
Copying the J2EE 1.4 configuration from a 6.x portal configuration will not work.
2. Or, you could manually copy the J2EE 1.3 configuration files to a 6.x portal (this solution has
been successfully tested). However, this solution implies that generally WS-Security 1.0 draft
13 messages are used in the environment.
Important: These are only possible solutions to work around the problem, and they are not
officially supported by IBM. Therefore, the recommendation is to use the same version of
WebSphere Portal for both the Producer and Consumer side.
9.1.1.2 Using the LTPA token for user identity propagation
When using the LTPA token for single-sign-on in your environment, a common setup is to
propagate the LTPA token also on the Web Service message level, allowing the Producer to assert
the user identity. Such a setup requires that both the Producer and the Consumer portal share the
same user registry and single-sign-on realm (that is, they use the same LTPA keys for token
encryption). The LTPA token containing the user id is wrapped inside the SOAP header of each
WSRP request. The token is extracted from the SOAP request at the Producer portal, and the
corresponding security context is created. The resulting request processing on the Producer runs
under the same user identity as the initial request on the Consumer portal. Figure 23 depicts the
LTPA token-based user identity propagation mechanism.
Figure 23: WSRP LTPA token- based user identity propagation
Page 44 of 50
WebSphere Portal 6.0 Security, Version 6.0.0
9.1.1.3 Using different WS-Security configurations for Producers
Beginning with WebSphere Portal V.0, the Consumer portal can specify different WS-Security
configurations for different Producers, enabling the Consumer portal to communicate securely with
a set of Producers, each requiring a distinct security setup. This is done by creating the necessary
Web Service security configuration files with an assembly tool and associating them to a
representation of a particular Producer on the Consumer portal. To simplify this manual process,
you could define several security configuration templates and then associate them to particular
Producers.
9.1.2 Securing WSRP services on the transport layer
In addition to securing WSRP services on the Web Service layer, you can use SSL to provide
message-level integrity, confidentiality, and mutual authentication by client certificates.
To provide message-level integrity and confidentiality, you can configure the connections from
Producers to Consumers to be secured by SSL. You configure the WSRP Web Services in the
WebSphere Portal EAR file for SSL using the WebSphere Application Server Administrative
Console.
Additionally, you can use SSL for client certificate based authentication from Consumer to
Producer. This can be used alone or combined with the previously described WS-Security identity
propagation.
If you use SSL for client certificate based authentication alone, you can provide limited user identity
propagation based on the client certificate installed at the WSRP Consumer. In such a setup,
Consumer and Producer portals can each have different user registries. However, you must define
either a shared user ID or a corresponding certificate mapping for the mutually authenticated SSL
connection.
The user ID representing the Consumer portal is pulled from the client certificate installed at the
Consumer portal and sent with all WSRP requests, independent of the identity of the user that was
authenticated against the Consumer portal. Therefore, this user ID is shared by all users of the
client portal when connecting to a Producer portal. In this configuration, personalization information
for the end user identity is added to the SOAP request as meta-data. As mentioned at the
beginning of this section, this personalization information is not reliable information from a security
point of view. So the Producer portlet should only use this identity for displaying personalized data;
all access control decisions on the Producer portal are made based on the reliable shared user
identity coming from the Consumer certificate.
When using both SSL client certificate and WS-Security for identity propagation, the SSL mutual
authentication is done first to establish trust in the caller. Only if the client certificate is verified
correctly, is the request forwarded to the Web Service Engine that establishes a security context
based on the WS-Security token. The WS-Security identity information then supersedes the one
from the client certificate, which means the user identity on the Producer will be taken from the
SOAP security header and not from the SSL client certificate.
9.2 Enforcing access control with WSRP security
Access control for WSRP connections can be enforced at both the Producer and Consumer sides.
On the Consumer, the registration of WSRP Producers and the integration of portlets from the
Producer side are controlled by Portal Access Control. On the Producer, the enforcement of the
access control decision can be enabled or suppressed by setting the configuration property,
wsrp.security.enabled, in the properties of the Portal Configuration Service.
•
If wsrp.security.enabled is set to true, then all access control decisions in the
producing portal are based on the authenticated principal.
Page 45 of 50
WebSphere Portal 6.0 Security, Version 6.0.0
•
If wsrp.security.enabled is set to false, then the producing portal does not enforce any
access control on incoming client portal WSRP requests.
All access control decisions are based exclusively on the security context established by
WebSphere Application Server. When using identity propagation with WS-Security, the user
authenticated on the client portal is taken for access control checks. If no identity propagation is
configured, but SSL client certificate authentication is enabled, then the ID of the certificate is used
for all access control checks. If none of the previously mentioned authentication methods is used,
then the request is treated as un-authenticated, taking the anonymous Portal user for access
control checks.
9.3 WSRP security and the Credential Vault
WSRP portlets running in a Consumer portal can make use of the Credential Vault without
restrictions, if identity propagation is being used. They can access both system-managed slots and
any user-managed slot for the respective user ID. The credentials are stored in the Credential Vault
located at the Producer portal, in this case.
If there is no identity propagation and there is only a shared user ID based on the Consumer portal
SSL client certificate, then the Credential Vault access is limited; only system-managed slots can
be used. User-managed slots in the user segment must not be used because the end user identity
is not available and is mapped to the shared user identity of the client portal.
9.4 WSRP and Cross Site Scripting
Putting a WSRP-provided portlet on a portal page results in the markup produced by the remote
portlet being added to the markup of the local page. As a result, if this markup contains active
content, it can access the markup provided by other (local) portlets on that page and other browser
properties such as cookies. In other words, importing a malicious portlet using WSRP can result in
this portlet stealing document cookies and other information rendered by other portlets on the
consumer side. Therefore, only trusted portlets must be integrated into a portal to prevent this kind
of information leakage at the consumer side.
10 Summary
WebSphere Portal offers state-of-the-art protection through industry standard security protocols
and crypto algorithms. A single sign-on concept for the portal front-end and for back-end
applications provides a superior user experience. WebSphere Portal can be flexibly integrated with
existing corporate user directories and with products for authentication, authorization, and
administration. In addition to password-based authentication, stronger methods such as X.509
certificates or one-time passwords (with WebSEAL) are supported. Secure communication can be
used wherever the transmitted information is sensitive.
Page 46 of 50
WebSphere Portal 6.0 Security, Version 6.0.0
11 Resources
12 About the authors
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].
Stefan Schmitt joined IBM in 2000 and has worked in the WebSphere Portal
development team since the WebSphere Portal 1.0 release. He leads the
security team of IBM WebSphere Portal, works as the IBM WebSphere Portal
Vulnerability contact and is responsible for the architecture and design of the
user management functions available in IBM WebSphere Portal. Prior to his
work at IBM, Stefan studied Information Technology at the University of
Cooperative Education Stuttgart.
Holger Waterstrat joined IBM in 2001 and worked in the pervasive computing
development area. He joined the WebSphere Portal development team in the
same year and is currently working in the security team.
Holger received a Diploma of Computer Science from the Technical
University of Berlin.
Andreas Zehnpfenning received his Diploma of Computer Science from the
University of Stuttgart. After completing his diploma thesis on speech
synthesis at IBM’s voice team in 2005, he joined the WebSphere Portal
security team.
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.
Richard Jacob joined the IBM WebSphere Portal development team in 2002.
He is responsible for the WSRP architecture in WebSphere Portal and for the
WSRP standardization and specification. He represents the IBM development
team at the OASIS Web Services for Remote Portlets technical committee,
where he is a core member. Prior to his work in the Portal team, Richard
graduated from University of Stuttgart, Germany and received a Diploma of
Computer Science in 2000. He worked for a German telecommunications
company where he gained experience in networking, distributed systems,
systems management and security.
Page 47 of 50
WebSphere Portal 6.0 Security, Version 6.0.0
Thomas Hurek is a software architect at the German IBM development lab.
He has technical responsibility for fixpacks and Level 3 maintenance in the
WebSphere Portal development team. You can contact Thomas at
[email protected].
13 Glossary
Credential Vault
Service
Portlet service for accessing credentials. This service supports single sign-on.
Credential Vault
Portal component for storing credentials. Portlets access the credential vault
through the credential service.
CAI
Collaborative Application Infrastructure
DMZ
De-Militarized Zone
HTTPS
HTTP over SSL
IDS
Intrusion Detection System, monitoring network and machines for break-ins
IPSec
Secure IP, the security functions of IP version 6 ported into IP version 4
JAAS
Java Authentication and Authorization Service
JCR
Java Content Repository
LTPA
Lightweight Third Party Authentication
MAC
Message Authentication Code
POS
Protected Object Space, the set of objects protected by an access control
system
SSL
Secure Sockets Layer
SSO
Single Sign-On
TAI
Trust Association Interceptor
TLS
Transport Layer Security, an IETF Standard version of SSL
VPN
Virtual Private Network
14 Product names
Company
Product Name
Entrust
GetAccess
IBM
Edge Server
Tivoli Access Manager for e-business
WebSEAL and Tivoli Access Manager Plugin for Edge Server
WebSphere Portal
WebSphere Application Server
Microsoft
IIS (Internet Information Server)
Windows
Netegrity
SiteMinder and SiteMinder Web Agent
Page 48 of 50
WebSphere Portal 6.0 Security, Version 6.0.0
RSA
Cleartrust
15 Acknowledgements
The authors would like to acknowledge the valuable information or feedback we received from our
colleagues: Carol Jones, Don Jones, Jochen Burkhardt, Jeff Crume, Christian Karpp, Uwe
Hansmann, Karl Bishop, Keys Botzum, Stephan Laertz, Andreas Seidel, and Ralph Klaassen.
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 can be trademarks or service marks of others.
IBM copyright and trademark information: http://www.ibm.com/legal/copytrade.phtml
Page 49 of 50
1
[]
WebSphere Portal Family
http://www.ibm.com/software/genservers/portal/
2
[]
IETF RFC 2401
http://www.ietf.org/rfc/rfc2401.txt
3
[]
IETF RFC 2246
http://www.ietf.org/rfc/rfc2246.txt
4
[]
Guidelines on Firewalls and Firewall Policy – Recommendations of the National Institute of
Standards and Technology, by John Wack, Computer Security Division Information Technology
Laboratory National Institute of Standards and Technology
http://csrc.nist.gov/publications/nistpubs/800-41/sp800-41.pdf
5
[]
IBM WebSphere Application Server, Version 6 Security
http://www.ibm.com/software/webservers/appserv/was/library/library60.html
6
[]
WebSphere Application Server V6 Security Handbook Series, SG24-6316-00
http://www.redbooks.ibm.com/redbooks/pdfs/sg246316.pdf
7
[]
JAAS Documentation and Specification
http://java.sun.com/products/jaas/
8
[]
Tivoli Access Manager for e-Business
http://www.ibm.com/software/tivoli/products/access-mgr-e-bus/
9
[]
Advanced authentication in WebSphere Application Server
http://www-128.ibm.com/developerworks/websphere/techjournal/0508_benantar/0508_benantar.html
10 []
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/0606_buehler.html
11 []
Secure Socket Layer overview in the WebSphere Portal InfoCenter
http://publib.boulder.ibm.com/infocenter/wpdoc/v6r0/topic/com.ibm.wp.ent.doc/wpf/ssloverview.html
12 []
WebSphere Portal 6.0 product documentation, including the InfoCenter
http://www.ibm.com/developerworks/websphere/zones/portal/proddoc.html
13 []
Building composite applications and templates in WebSphere Portal V6
http://www.ibm.com/developerworks/websphere/library/techarticles/0608_stober/0608_stober.html
14 [] Enable the audit service in the WebSphere Portal InfoCenter
http://publib.boulder.ibm.com/infocenter/wpdoc/v6r0/topic/com.ibm.wp.ent.doc/wpf/sec_audit.html
15 []
Java 2 Platform Security Architecture, by Li Gong
http://java.sun.com/j2se/1.4.2/docs/guide/security/spec/security-spec.doc.html
16 [] Prevent a cross-site scripting attack
http://www.ibm.com/developerworks/web/library/wa-secxss/?ca=dnt-55
17 []
Web Services for Remote Portlets Specification Version 1.0, by OASIS
http://www.oasis-open.org/committees/download.php/3343/oasis-200304-wsrp-specification-1.0.pdf
18 []
Web Services Security: SOAP Message Security 1.0, by OASIS
http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-soap-message-security-1.0.pdf
19 [] WebSphere Application Server zone, including access to the InfoCenter
http://www.ibm.com/developerworks/websphere/zones/was/
[20] WebSphere Portal zone
http://www.ibm.com/developerworks/websphere/zones/portal/