ibm websphere portal v6.0 security overviewpublic.dhe.ibm.com/software/dw/wes/pdf/0611... ·...

WebSphere Portal 6.0 Security, Version 6.0.0

IBM WebSphere Portal V6.0 Security OverviewLevel: Advanced

Dr. Dieter Buehler, WebSphere Portal Security Architect, IBMStefan Schmitt, WebSphere Portal Security Lead, IBMHolger Waterstrat, WebSphere Portal Security Team, IBMAndreas Zehnpfenning, WebSphere Portal Security Team, IBMJan-Paul Buchwald, WebSphere Portal Security Team, IBMRichard Jacob, WebSphere Portal WSRP Lead, IBMThomas 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.

of 50


Table of contents1 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

of 50


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

of 50


1 IntroductionThis 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.

of 50


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 portal-specific 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.

of 50


1.1 Revisiting basic Internet securityBecause 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 communicationThe 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.

of 50


1.1.2 FirewallsIn 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].

of 50


2 Portal deployment scenariosWhen 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 networksFirst, 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 portalsFor 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.

of 50


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 authenticationIf 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 proxyFor 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.

of 50


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 proxiesThe 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.

of 50


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 AuthenticationThe 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:

of 50


• 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 SecurityTo 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.

of 50


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 InterceptorA 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.

of 50


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.

of 50


Figure 8: Flow of control for a request passing through an external authentication proxy

3.3 Requests in a session which is already authenticatedAfter 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.

of 50


Figure 9: Flow for a request that is already authenticated

3.4 User registryThe 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

Description

LDAP + database LDAP or

custom registry for WebSphere Application Server provided by WebSphere Portal

The authentication registry is a directory server (LDAP), and profile information is split between both LDAP and a database. The degree of this split is configurable (for example, what attributes are stored in LDAP and what in the database).

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.

of 50


Multiple repositories

Custom registry for WebSphere Application Server provided by WebSphere Portal

The authentication registry can be a combination of one or multiple directory servers (LDAP) and a database.

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 WebSphere Application Server provided by customer

The customer supplies a custom user registry. Profile and authentication information is held in this custom registry.

3.5 Portal loginAfter 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 loginIf 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.

of 50


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 LogoutThe 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

of 50


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 processesWebSphere 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.

of 50


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 applicationsYou 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 portalWith 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

of 50


with the Tivoli Access Manager Web server plug-in for IIS. You would configure it so that an e-Community is established between the IIS plug-in and WebSEAL.

4.2 Portal-to-back-end SSOSome 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 worksWebSphere 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.

of 50


• 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. Administrator-managed 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 objectsThe 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.

of 50


Listing 1. Passive credential object use (pseudo code)

// 1. Retrieve the credential object from the credential vaultUserPasswordPassiveCredential credential = (UserPasswordPassiveCredential)

service.getCredential(slotId, "UserPasswordPassive", null, porletRequest);

// 2. Extract the actual secret out of the credential objectUserPasswordCredentialSecret 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 vaultHttpFormBasedAuthCredential credential = (HttpFormBasedAuthCredential)

service.getCredential(slotId, "HttpFormBasedAuth", config, request);

// 2. Log into the back-end systemcredential.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 systemcredential.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.

of 50


Figure 13: Portlet using an active credential object for back-end SSO

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 form-

based 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.

of 50

1b. Retrieve Secret

1a. R

etrie

ve

C

rede

ntia

l

Portal Engine

Credential Vault Portlet Service

Portl

et A

PI

Portlet

Active Credential

Vault Store

Back-end System4. Send Business Request

2a. login()3. Get Authenticated Connection 2b. Authenticate


• 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 communicationSecure 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.

of 50


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.

of 50


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.

of 50


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 certificatesThe 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.

of 50


6 Securing back-end connectionsSome 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 applicationsUsing 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 resourcesAuthorization 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 conceptsFirst, we define key terminology and concepts involved in WebSphere Portal's access control capabilities.

7.1.1 Sensitive operationsUsers (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 resourcesThose 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

of 50


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 typesA 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

of 50


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.

of 50


Figure 19: Role type hierarchy

7.1.4 Role assignment and inheritanceIn 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.

of 50


7.1.5 Role blocksYou 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 ownershipEach 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 pagesPortal 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 domainsWebSphere 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).

of 50


• 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

of 50


7.2 Delegating access control administrationPortal 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 sub-administrators 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

of 50


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 systemsThere 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

of 50


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 controlYou 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.

of 50

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 non-inherited 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>  <role-block type="inheritance" actionset="Manager"/> <role-block type="inheritance" actionset="User"/>

 <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.

of 50


<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 ScriptingIn 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 firstif { $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

of 50


#check if the List has been changed and write back if neededif [$PacList modified numeric] { $Access setacl [$PacList done]} #show the new active settings$PacList view [$Access getacl Content [$Content current]]

#list all principals in all listsforeach 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 AuditingWebSphere 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

of 50


8 Portlet security

8.1 Supporting Java 2 Platform SecurityJava 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.

of 50


8.2 Verifying secure connectionsSome 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 attacksBecause 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 ProtectionWebSphere 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.

of 50


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 SecurityWebSphere 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 portletsIn 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 WS-Security 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 WS-Security 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 WS-Security 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

of 50


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

of 50


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 layerIn 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 securityAccess 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.

of 50


• 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 VaultWSRP 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 ScriptingPutting 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 SummaryWebSphere 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.

of 50


11 Resources

12 About the authorsDr. 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.

of 50

mailto:[email protected]


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 GlossaryCredential 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 namesCompany 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

of 50

mailto:[email protected]


RSA Cleartrust

15 AcknowledgementsThe 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

of 50

http://www.ibm.com/legal/copytrade.phtml

1 [] WebSphere Portal Familyhttp://www.ibm.com/software/genservers/portal/

2 [] IETF RFC 2401http://www.ietf.org/rfc/rfc2401.txt

3 [] IETF RFC 2246http://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 Technologyhttp://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 Specificationhttp://java.sun.com/products/jaas/

8 [] Tivoli Access Manager for e-Businesshttp://www.ibm.com/software/tivoli/products/access-mgr-e-bus/

9 [] Advanced authentication in WebSphere Application Serverhttp://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 systemhttp://www.ibm.com/developerworks/websphere/library/techarticles/0606_buehler/0606_buehler.html

11 [] Secure Socket Layer overview in the WebSphere Portal InfoCenterhttp://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 InfoCenterhttp://www.ibm.com/developerworks/websphere/zones/portal/proddoc.html

13 [] Building composite applications and templates in WebSphere Portal V6http://www.ibm.com/developerworks/websphere/library/techarticles/0608_stober/0608_stober.html

14 [] Enable the audit service in the WebSphere Portal InfoCenterhttp://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 Gonghttp://java.sun.com/j2se/1.4.2/docs/guide/security/spec/security-spec.doc.html

16 [] Prevent a cross-site scripting attackhttp://www.ibm.com/developerworks/web/library/wa-secxss/?ca=dnt-55

17 [] Web Services for Remote Portlets Specification Version 1.0, by OASIShttp://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 OASIShttp://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 InfoCenterhttp://www.ibm.com/developerworks/websphere/zones/was/

[20] WebSphere Portal zonehttp://www.ibm.com/developerworks/websphere/zones/portal/

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

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

http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-soap-message-security-1.0.pdf

http://www.oasis-open.org/committees/download.php/3343/oasis-200304-wsrp-specification-1.0.pdf

http://www.ibm.com/developerworks/web/library/wa-secxss/?ca=dnt-55

http://java.sun.com/j2se/1.4.2/docs/guide/security/spec/security-spec.doc.html

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

http://www.ibm.com/developerworks/websphere/library/techarticles/0608_stober/0608_stober.html

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

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

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

http://www-128.ibm.com/developerworks/websphere/techjournal/0508_benantar/0508_benantar.html

http://www.ibm.com/software/tivoli/products/access-mgr-e-bus/

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

http://www.redbooks.ibm.com/redbooks/pdfs/sg246316.pdf

http://www.ibm.com/software/webservers/appserv/was/library/library60.html

http://csrc.nist.gov/publications/nistpubs/800-41/sp800-41.pdf

http://www.ietf.org/rfc/rfc2246.txt

http://www.ietf.org/rfc/rfc2401.txt

http://www.ibm.com/software/genservers/portal/