Portal configuration services

Portal configuration services

+
Search Tips | Advanced Search

Overview
Configuration Service
Deployment Service
DataStore Service
Loader Service
Localizer Service
Navigator Service
Registry Service
PortletContainer Service

Parallel portlet rendering

Content Access Service
Cache Manager Service
State Manager Service
Administrator Unique Names Mapping Service
Portal Security Services

Access Control Data Management Service
Authentication Service
Credential Vault Service
External Access Control Service
Auditing Service

Puma and Puma Validation services

Puma service
Puma Validation service

Overview

The configuration for each service is stored in and accessible through the IBM WAS Administrative Console.
The following sections describe the services and their configuration that may be of interest to the portal administrator. Files and services which are not described in the following are purely for portal internal usage. Do not modify them in any way.
Default values are in parentheses. Parameters marked with <none> have no default values.
See also...

Set configuration properties
Configuration Services List

Configuration Service

The Configuration Service is responsible for collecting the most essential configuration data of the portal engine. Many of these parameters are set by the installation procedure. Therefore, plan well ahead and apply special care when modifying these parameters.
The Configuration Service also holds the configuration properties for WSRP services.

was.home = (${WAS_INSTALL_ROOT})

Absolute path to the install directory of WAS.

wps.home = (${WPS_INSTALL_ROOT})

Home (or install) directory of the WebSphere Portal.

command.sessionvalidator = (SessionValidatorAuth)

Session validator command.

command.login = (LoginUserAuth)

Login command.

command.logout = (LogoutUserAuth)

Logout command.

redirect.login = (true)

Turn on user-defined redirection after successful login.
If a URL has been specified under redirect.login.url, that URL is used as the URL for the redirection.
If no URL is specified, the portal determines the default page for the current user and sends a redirect to that page in the protected portal area.

redirect.login.ssl = (false)

Turn on SSL in the system-defined redirection after successful login.
If no URL is specified, the redirect URL uses HTTPS.

redirect.login.url [optional] = <none>

Redirection after successful login.
If no URL is specified, the portal determines the default page for the current user and sends a redirect to that page in the protected portal area.

redirect.login.authenticated.url [optional] = <none>

URL for redirection after the first access to a protected page when the user has already been authenticated by an external security manager (TAI) and a portal session does not exist yet.
If no URL is specified, the portal either displays the protected page that was originally requested, or, if session resume is enabled, the last page that the user had accessed in the previous session.

redirect.logout = (false)

Turn on user-defined redirection after successful logout.
If a URL has been specified under redirect.logout.url, that URL is used as the URL for the redirection.
If no URL is specified, the portal determines the default page in the public portal area and sends a redirect to that page.

redirect.logout.ssl = (false)

Turn on SSL in system-defined redirection after successful logout. If no URL is specified, the redirect URL uses HTTPS.

redirect.logout.url = <none>

Redirection after successful logout.
If no URL is specified, the portal determines the default page in the public portal area and sends a redirect to that page.

multiple.realms.enabled = false

Multiple Realms Support parameters to allow login with uid@realm.

multiple.realms.login.default.realm = <none>

Multiple Realms Support parameters to allow login with uid@realm.

multiple.realms.user.dn.template = <none>

Multiple Realms Support parameters to allow login with uid@realm.

host.name = <none>

Default is that no value exists for host name. In this case, portal URLs start with the hostname of the incoming request.
To have the host name in URLs be static, enter a hostname. For example, in case of a cluster installation enter the name of the network traffic dispatcher
If a hostname is entered, this entry is used to create the portal URLs.

host.port.http = <none>

HTTP port (normally 80).

host.port.https = <none>

HTTP-SSL port (normally 443).

security.css.protection = (true)

Whether Cross-Site-Scripting security protection is turned on. The default is true for enabling the protection.

redirect.commands = (false)

Specifies that a portal command is followed with an HTTP redirect. This way URLs can be bookmarked. Using this feature results in a certain performance overhead. Therefore it should only be used if needed.

uri.context.path = (/wps)

Context path under which the portal is running.

uri.context.path.facade = (/wsrp)

Context path for the additional WAR file that is used as a facade Web application for a WSRP implementation.
Allows us to use SSL with client authentication for WSRP and simultaneously use other means of authentication for the portal, for example form based authentication. This separation is required as J2EE allows only for one authentication mechanism per WAR file.

uri.home.public = (/portal)

Servlet context of the portal engine for public (or anonymous) pages, i. e. pages that users can view without entering a user ID or password.

uri.home.protected = (/myportal)

Servlet context portal engine for protected (or personal) pages. i. e. pages that users can only view by entering a user ID and password.

uri.home.doc = (/doc)

Servlet context of the portal engine for the documentation area.

uri.home.substitution = (false)

Determines whether a public URL should be translated to a protected URL if a user session exists.

persistent.session.level = (0)

Determines the level on which the persistent session should operate. (persistent session state)

persistent.session.option = (0)

Determines whether the user gets the option to resume the session.
If set to 0, the level setting for the property persistent.session.level is applied during login, and the user has no choice whether to resume the previous session or not.
If set to 1 you give users the resume option.

session.security.use.errorcode = (true)

Whether the portal performs a redirect or displays an HTTP error, if session security support is enabled for the portal server and the user in the session does not correspond to the authenticated user in the request.
Session security support is a hardening feature of WAS. We can activate it for each application server in the application console under...
Web Container Settings | Session Management

If this session security support is active, the application server checks for each authenticated request whether the user who owns the current session matches the user who originated the request. For example, this can be determined by the LTPA token. The portal service configuration property only specifies how the portal behaves, if it detects a mismatch between the session user and the authenticated user.
If set to true, the portal returns the HTTP error code that you define by the property session.security.errorcode. This typically results in an appropriate error message being displayed.
If set to false, we can specify a redirect URL by using the property session.security.redirecturl. For example, we can redirect to a specific error page which is then displayed to the user.
By default this property is set to true.

session.security.errorcode = (409)

HTTP error code that is returned if all of the following conditions apply:

Session security support is enabled in the WAS.

The property session.security.use.errorcode is set to true.

A mismatch of the user in the session and the authenticated user is detected.

You must specify a valid HTTP error code. The default is error code 409.

session.security.redirecturl = <none>

Redirect URL to which portal redirects if all of the following conditions apply:

Session security support is enabled in the WAS.

The property session.security.use.errorcode is set to false.

A mismatch of the user in the session and the authenticated user is detected.

You must specify a value for this property, if the property session.security.use.errorcode is set to false. This property has no default.

portal.session.protection = (true)

For each authenticated portal request, portal checks whether the user in the portal session matches the calling user of the current request. If this results in a mismatch, the portal invalidates the existing session and creates a new one for the calling user to make sure that both identities match. The portal provides this hardening feature, which is independent of the session security support provided by WAS. By default this property is set to true, therefore by default the portal performs this check.

portal.enable.filtering = (true)

This flag determines whether the portal should use Portal Filtering or not. The default is true.

portlet.url.find = <none>

URL that is used for find and set in global settings portlet.

portlets.unauthorized.visible = (false)

Determines what a user sees if they are not authorized to view a portlet.

allow.derived.titles = (true)

Determines if the title and description of derived pages can be redefined by users. If the value is set to false, titles and description of pages can only be changed on non-derived pages.

wps.mappingurl.portal_url_identifier = (/!ut/p)

Identifier for Portal URLs.
wps.mappingurl.enabled = (true)

Defines whether URL Mapping is enabled or not. Possible values are true to enable URL Mapping, or false to disable URL Mapping.

navigation.portletmenu.mode = (1)

Defines in which way portlet menus are integrated in the overall portal navigation menu structure. Portlet menus are navigation parts that are provided by the portlet itself. They can be added as a subtree to the navigation menu item that references the page in which the portlet resides. This parameter has the following three options:

0 Disabled Portlet Menus are not displayed in the navigation menu at all.
1 Current selection Only the portlet menus of the portlets that reside on the currently selected page are added below the navigation menu item for that page. This is the default value.
2 Everything The portlet menus of all portlets on all pages are added below the appropriate navigation menu items in the navigation tree.

navigation.expansion.defaultstate = (false)

Determines whether the nodes in the navigation tree are expanded or collapsed by default. The default is false, which means that the nodes are collapsed. Some exceptions apply; for example, the Portal Administration navigation tree is expanded by default.

page.reload.interval = (0)

Interval in minutes after which pages should be reloaded for an authenticated user. The reload respects the most current access control settings for that user. If this value is set to zero, no automatic reload occurs during the session.

PortletResponse headers

portletcontainer.response.headers.additionallyNotAllowed = <none>

There is a predefined set of response header fields which are not allowed to be used in portlet response fields. In addition to these predefined header fields it is possible to define additional fields, which are then also prohibited to be included into a portlet response header.
Values must be separated by commas, if more than one field is specified.
The following list shows the header fields of the HTTP 1.1 (RFC 2616) specification that are by default not allowed to be set:

6.2 Response Header Fields
The response-header fields allow the server to pass additional information about the response that cannot be placed in the Status-Line. These header fields give information about the server and about further access to the resource identified by the Request-URI.

Accept-Ranges Section 14.5
Location Section 14.30
Proxy-Authenticate Section 14.33
Server Section 14.38
Vary Section 14.44
WWW-Authenticate Section 14.47

7.1 Entity Header Fields
Entity-header fields define meta information about the entity-body or, if no body is present, about the resource identified by the request. Some of this meta information is optional; some might be required by portions of this specification.

Allow Section 14.7
Content-Encoding Section 14.11
Content-Language Section 14.12
Content-Length Section 14.13
Content-Location Section 14.14
Content-MD5 Section 14.15
Content-Range Section 14.16
Content-Type Section 14.17
Expires Section 14.21
Last-Modified Section 14.29

4.2 Message Headers
HTTP header fields, which include general-header (section 4.5), request-header (section 5.3), response-header (section 6.2), and entity-header (section 7.1) fields, follow the same generic format as that given in Section 3.1 of RFC 822 [9]. Each header field consists of a name followed by a colon ( : ) and the field value. Field names are case-insensitive.

portletcontainer.response.headers.forceAllowed = <none>

Re-enable the usage of the fields listed above which are by default prohibited header fields. Values must be separated by commas, if more than one field is specified.

xmlaccess.allowshortnames = (false)

Distinguishes DNs from short names in the subjectID. All subjectID attributes are treated as IDs and never as short names.

portlet.enable.transcoding = (true)

Determines whether transcoding is enabled.

portlet.automaximize = (false)

If set to true, the portlet window is maximized when a portlet is set into edit, configure or help mode.

Deployment Service

The Deployment Service provides services for accessing the configuration parameters required for the portlet deployment.
The portlet deployment component is responsible for the integration of portlets into the portal. It handles the correct deployment of portlet applications and their WAR files into WebSphere Portal and WAS. It uses the WAS management services for the physical deployment and management of war files in the WAS.
Management of war files includes...

Installing
Removing
Redeploying
Starting
Stopping

...portlet applications.
Portlet applications appear in the Enterprise Application list on the administrative console of WAS. However, you should never manage them from outside the portal. Instead, manage them by using the WebSphere Portal administration portlets or the XML configuration interface of the portal.
You recognize Web applications which comprise a portlet application by their administrative name, also called the display name. It is shown in the WAS administrative console. We can identify the name of such a portlet application by a portal specific identifier suffix...
_PA_<id>

...which is appended to the name. For example...
World_Clock_PA_3v7zl6w

The name in turn is derived from the name of the WAR file when the portlet application was first installed. This administrative name never changes, even if a different filename is used to update the portlet application.
In the following list of parameters the values given in parentheses are the default values.

was.admin.host = (localhost)

The WAS administrative host name. Used to adapt to the WAS bootstrap host name, if the default is not applicable.

use.admin.user = (true)

Select between two user authentication mechanisms for the portal Portlet Deployment Manager to authenticate with the WAS administrative services when portal security is enabled. Specify one of the following two possible values:

true

Use a single preset shared user ID for all portal administrative users who issue WAR deployment requests. This is the default. This is a separate user ID that is common for all users who are allowed to perform install or manage applications tasks. You must register this user ID with WAS Console User Administrator rights.

false

Use the actual user ID by which the administrator issues the WAR deployment request. Every portal user with portlet deployment rights must be added to the WAS Console User list with administrator rights. Alternatively, we can add the complete group of portal administrators to the WAS Console Group administrator rights.

For more information about how to use this property refer to Deploying portlets in a secure environment.

update.portlet.preserves.config.settings = (true)

This controls whether portlet configuration parameters from portlet.xml should replace the existing ones, or whether the existing parameters should be preserved, and only new ones be added.
If set to true, this prevents modifications made by an administrative user from being overwritten with default values that the portlet developer put into the portlet.xml in the new WAR file.
The following fields are preserved from modification by an updated portlet.xml file:

Portal resource Standard API portlet application IBM API portlet application
Portlet Application Default locale N/A
Title Title
User attributes Context parameter
Portlet Name Name
Title Title
Short title Short title
Keywords Keywords
Description Description
Default locale and description Default locale
Initialization parameter Initialization parameter
Preferences N/A
Remote cache settings Cache settings
Expiration date settings N/A
Servlet N/A Mappings

was.notification.timeout = (60)

Timeout value (in seconds).
Specifies how many seconds the deployment tasks waits for an application server event during the management of war files. This value may have to be increased on large portal installations.

portletapp.starting.weight = (100)

Starting weight of the portlet applications (war files).
To ensure the correct initialization sequence, this value must be higher than the starting weight of the portal itself.

portletapp.shared.library.list

List of library references which are added to each deployed WAR file during deployment.
We can specify multiple references separated by a comma (, ). The library references must have already been defined in the application server, and the JAR files must have already been deployed at the location assigned in the reference definition.

portletapp.reload.enabled = preserve

Define the value for the reload property of the deployed WAR file.
This property can have the following values:

true

Enable reloading mode for all war files. Use this value only for portlet development and portlet debugging purposes, but not for production environments.

false

Disable reloading mode for all war files. This is the default.

preserve

Setting from the file ibm-web-ext.xmi is applied, if available.

The default setting is false.
Do not enable reloading in a production environment. Enable reloading only for portlet development and portlet debugging purposes.

discard.config.interval = (60)

Minimum time interval for which the configuration service workspace that is used during WAR file deployment is kept. After this time expires, the workspace is discarded when the portal runs the next deployment task. The unit of measure is minutes. Valid values are listed in the following, together with their meaning:

1 Never discard the workspace.
0 Always discard the workspace immediately after the action that required the workspace has been completed.
> 0 Time interval (in minutes) for which a workspace is retained before it is discarded. It is then rebuilt for the next deployment task.

Notes:

Use good judgement when setting this property. The proper use of this setting must be a compromise between performance and workspace consumption for the following reasons:

Discarding the workspace frequently has a negative impact on deployment performance. The larger the portal installation is, the longer it takes to discard and rebuild the workspace to save the configuration changes during WAR file deployment.

However, retaining a workspace keeps the wp_xxx temporary directories in the WAS wstemp directory. Consequently, the temporary space that they occupy in the file system grows every time a WAR file is deployed and every time the portal is restarted.

The configuration service workspace is not discarded immediately after expiry of the time interval set. The cleanup is done the next time that a deployment operation is called. It checks for expired changes and discards the workspace that they occupy. If further deployment operations occurred after the last time that the timer interval expired and the workspace was released, the changes in the last allocated workspace remain in the file system even on portal shutdown. Nevertheless, the previous cleanup reduces the volume of occupied disk space to only those temporary files that were processed after the last cleanup interval.

The following values define file locations. All these settings have default values and should only be enabled and modified if the defaults are not appropriate.

application.repository.root.dir = (${WPS_INSTALL_ROOT})

Root directory where war files are stored for deployment.

application.repository.dir.name = (deployed)

Name of the subdirectory where.war and.ear files are stored.

jobs.root.dir = (${WPS_INSTALL_ROOT})

Root directory where job files are stored for deployment.

jobs.dir.name = (jobs)

Subdirectory name where job files are stored for deployment.

delete.temp.files = (true)

Determine whether temporary files that were created during deployment in the directory application.repository.dir.name/temp are deleted or kept. The default is true, which means that the files are deleted. Change the value to false only for debugging purposes so that we can view the content of the temporarily expanded WAR files. When you have completed debugging, change the value back to true and delete the directories manually. If you change the value to false, be aware that the hard drive space required by the temporary directory grows with each WAR file that you add or update.

shorten.deployment.names = (true)

Enforce shorter file names during deployment. Some platforms, such as Windows impose a limit to the length of a file path. This can cause deployment to fail if the resulting path is too long.

deployment.names.limit = (21)

Threshold value for portlet application file and display names. Longer names will be shortened if required.

The following setting is for debug purposes only. Enable it only when instructed to do so by support personnel.

deployment.debug.log.times = (false)

DataStore Service

WebSphere Portal uses a database to store configuration data for pages, clients, markup, and all other resources. The database is created and configured as described under Installing databases and Transferring all domains.
For i5/OS, the database is configured as described under Transferring DB2 for iSeries manually.
The DataStore Service is responsible for managing the data source of the portal as configured while installing WebSphere Portal. Normally there should not be a need to modify any of the configuration parameters in the DataStore service. The DataStore service parameters are listed in the following:

scheduler.cleanup.enabled = (true)

Determines whether deletion of portal pages is performed later by the scheduled cleanup service, or immediately after the user completes the deletion task. This affects the deletion of portal pages and all their dependent resources, such as components and portlet instances. The default is true, which means that deletion of portal pages is delayed and performed by the cleanup service.
Even if this parameter is set to true and delayed cleanup, deleted pages are no longer visible to users immediately after deletion.
For details about this parameter and how to schedule the cleanup service, refer to Delayed cleanup of deleted portal pages.

datasource.machineid

Value for this parameter is equivalent to the MAC address of the server. It consists of a string of 12 hexadecimal figures.
Do not change the value for this parameter.

The following properties are domain specific properties. They are paired. The last three pairs are analog to the first pair. The possible valid values listed under the first property xxx.datasource.dbms of the first pair can also be specified for the first property of the following pairs.
Do not assign the same schema name twice for database domains that reside in the same database instance. For example, if the release database domain resides in a database named DB1 and uses the schema SCHEMA1, no other domain in the same database instance can use that same schema name SCHEMA1. This restriction applies to domains that are in the same database instance only. Using the same schema name more than once in different database instances of the same database management system is no problem.

rel.datasource.dbms = your_DBMS

Database management (DBMS) system for the release database domain. The default value is CLOUDSCAPE. Valid values are listed in the following table. They are also valid for the property xxx.datasource.dbms properties in the three property pairs listed further below.

DBMS used DBMS value for xxx.datasource.dbms properties
IBM Cloudscape CLOUDSCAPE
IBM DB2 Universal Database Enterprise Server Edition DB2
IBM DB2 Universal Database for iSeries DB2_ISERIES
IBM DB2 Universal Database for z/OS DB2_ZOS
Oracle Enterprise Edition ORACLE
Microsoft SQL Server Enterprise Edition SQLSERVER

rel.datasource.schema = ( RELEASE )

Schema that is used for database objects in the release database domain.

cust.datasource.dbms = your_DBMS

Database management system for the customization database domain. The default value is CLOUDSCAPE. For valid values refer to rel.datasource.dbms.

cust.datasource.schema = ( CUSTOMIZATION )

Schema that is used for database objects in the customization database domain.

comm.datasource.dbms = your_DBMS

Database management system for the community database domain. The default value is CLOUDSCAPE. For valid values refer to rel.datasource.dbms.

comm.datasource.schema = ( COMMUNITY )

Schema that is used for database objects in the community database domain.

jcr.datasource.dbms = your_DBMS

Database management system for the JCR database domain. The default value is CLOUDSCAPE. For valid values refer to rel.datasource.dbms.

jcr.datasource.schema = ( JCR )

Schema that is used for database objects in the JCR database domain.

The following property specifies the database domain tracking daemon setting:

domain.tracker.wait = (1000)

Time for which the domain tracking daemon waits for a response by the database domain until it polls again. The value is specified in milliseconds. The default value is 1000 (milliseconds), which is equivalent to 1 second.
This daemon does not poll continuously, but only in case of errors. Therefore increasing this value will not reduce normal database traffic.

For further information about data sources and their configuration, refer to the WAS Handbook.

Loader Service

The Loader Service is responsible for dynamically loading class files in four categories:

commands
screen templates
skin templates
theme templates

The service does so by looking up a given (class) name in different packages. Upon loading the respective class file, an instance of that class is returned. To optimize the efficiency, the implementation of the service is free to cache loaded class files or instances and return a cached instance. That means, that the implementation of any such classes must be thread-safe.
In cases where additional or alternative commands are required, the following configuration properties can be modified:

command.path

Package prefix(es) in which commands are searched.

Localizer Service

The Localizer Service provides access to the configured default locale and the system default locale. It also provides a list of supported bidirectional languages.
Giving the system default locale is necessary because Locale.getDefault() is set to the portal default.
Although the locale is set during installation time, it is possible to change the locale at a later time by modifying the following properties in the LocalizerService:

locale.default.language

Language of the locale, for example, EN or PT.

locale.default.country

Country or region code of the locale, for example, US or BR.

locale.default.variant

Variant code of the locale.

The default language must be supported by the portal. If we leave all three parameters without a specified value, the system locale is used as the default locale.
All parameters are case-insensitive. The ISO standard ISO-639 is used for the language codes of most languages. For Hebrew the old language code iw is used. The ISO standard ISO-3166 is used for the country/region codes.

Navigator Service

Specify a number of settings, including cache scope and cache expiration.

Key Meaning Default value
public.session Specifies whether an anonymous user always has a public.session. This may be useful when a portlet requires a session for anonymous users. To enable public sessions for pages that anonymous users can view without logging in, set this parameter to true.
The setting of public.session influences the remote cache scope for public pages. If public.session is set to true, then the cache scope is set to non-shared (private). If public.session is set to false, then the cache scope is set to shared (public).

Setting public.session to true reduces portal performance.
false
public.expires Specifies the cache expiration time (in seconds) for caches outside of the portal and for unauthenticated pages only. These caches must adhere to the HTTP 1.1 specification (RFC 2616). The public.expires key specifies the time after which HTTP caches should drop the response. This can be further restricted by the remote.cache.expiration key (see below).
This value is used as a maximum value for the cache expiration time and as a global default value for unauthenticated pages. If the setting remote.cache.expiration is also set to a value greater than or equal to 0, the smaller one of the two values is used.
The portal calculates and aggregates the remote cache information, that is the scope and expiration time, by a number of parameters contributed by themes, pages, and portlets besides the settings described here. Therefore the portal can do any of the following internally while processing a request:

Reduce the cache lifetime

Reduce the cache scope, for example, from public (shared) to private (non-shared)

Switch off the overall cachability of pages.

Therefore this value might not be static for all responses resulting from requests to unauthenticated pages.
The response of the portal sets the following header fields:

The Expires header with the expiration time added to the system date and time of the portal

The Cache-Control : max-age = header with the expiration time as its parameter.

The default setting specified in this file is 60 seconds. If no value is specified, the portal defaults the value to 60 seconds.
60
remote.cache.expiration Specifies the maximum cache lifetime (in seconds) of a page, both public and private. Use this setting to specify a global value for the expiration of pages in remote caches. Setting this value to 0 switches caching off in remote caches. If the legacy setting is not available, this setting is used for authenticated and unauthenticated pages. If the legacy setting is available, then the smaller of the two values is used for unauthenticated pages only. In this case the remote.cache.expiration setting is used for authenticated pages in general. If theme, composition, and portlets contribute remote cache information, then the global settings also contribute to the information. In this case the lowest of the values of all contributors is used, including the global settings.
The default setting specified in this file is 60 seconds. If no value is specified, the portal defaults the value to zero (0 seconds).
0
remoteCacheInfo.response.header.vary Specifies the HTTP headers that force a proxy to cache different variants of the same URL. Use this setting to specify a comma separated list of HTTP header fields to which the portal should refer in its vary field of the generated HTTP response. This is required to ensure that proxy caches can invalidate entries in their cache if the specified header fields do not match from request to request. User-Agent

Registry Service

The RegistryService loads and caches a small number of objects which are regularly accessed in the portal engine. This improves performance, however the tradeoff is that the cached objects are possibly stale compared to their database counterparts. This applies particularly in a cluster environment. If the age of those objects causes a problem in the portal, try reducing the refresh rate for the respective entities.

default.interval = (1800)

Default interval for refreshing a bucket. The amount is specified in seconds, for example default.interval = 1800.

bucket.<bucket-name>.class

Type of class that the bucket with the given name is caching.

bucket.<bucket-name>.reload [optional = true]

Control whether or not the bucket with the given name is reloaded in frequent intervals.

bucket.<bucket-name>.interval = (default.interval)

Length of the reload interval for the bucket with the given name. If no value is set, the default.interval setting is used.

bucket.<bucket-name>.sorted [optional = false]

Control whether or not the bucket with the given name needs to keep the cached objects in a sorted order. The sorting order is determined by the objects themselves.

The bucket names are described in the following:

portlet

Portlet bucket is used to cache the database representation of all portlets stored in the database of this portal.

application

Application bucket is used to cache the database representation of all portlet applications stored in the portal database.

theme

Theme bucket is used to cache the database representation of all themes stored in the portal database.

language

Language bucket is used to cache the database representation of all languages that are stored in the portal database.

skin

Skin bucket is used to cache the database representation of all skins stored in the portal database.

language

Language bucket is used to cache the database representation of all languages stored in the portal database.

client

Client bucket is used to cache the database representation of all clients stored in the portal database.

markup

Markup bucket is used to cache the database representation of all markups stored in the portal database.

servlet

Servlet bucket is used to cache servlet configuration information stored in the portal database.

webmodule

Webmodule bucket is used to cache the database representation of all Web modules stored in the portal database.

PortletContainer Service

This section lists and describes the PortletContainer related settings.

legacy.portlet.enable.filtering = (true)

Flag that determines whether the portal should use Portlet Filtering or not.

Parallel portlet rendering

Use parallel portlet rendering to optimize the portal response time. When portlets on a page are rendered sequentially, some portlets can delay output from other portlets to the portal server. This delay can be caused, for example, by portlets that are waiting for a response from a remote service. Parallel portlet rendering can prevent this delay.
Enabling parallel portlet rendering provides a benefit if a high proportion of the portlets in the portal access remote locations to fetch the content they render. For example, if there are a large number of RSS portlets.
For portlets to be rendered parallel, the settings for both the portal AND the individual portlets need to be set to enable parallel portlet rendering. The default setting for the portal and for individual portlets is not to be rendered in parallel.
To change the setting for a portlet to parallel rendering...

Select...
Portal Administration | Portlet Management | Portlets

Select the desired portlet and click on the Configure (wrench) icon. The portal displays the panel for configuring the portlet.

Mark the Enable parallel rendering checkbox to enable parallel rendering for the portlet.

Alternatively we can also use the following parameter to enable parallel rendering of a portlet. You set this parameter as a configuration parameter in IBM portlets or as a read-only preference in standard portlets.

parallel = (false)

When you set this parameter to true, you indicate that the portlet can be rendered in parallel with other portlets on the page. The default is false.

Usually only some of the portlets that are configured for parallel rendering are actually rendered in parallel. Portlets for which the portal cannot provide a thread immediately are rendered sequentially.
We can configure portal wide parallel portlet rendering globally for all markups, or individually for the markups of the client devices that display the portal pages. This way, we can have multiple entries of the main parameters for parallel portlet rendering in the PortletContainerService. For example, we can have separate entries for different markups. Or we can enable parallel rendering for the portal, but disable it for one specific markup.
To enable parallel rendering makes sense only for markups that can display all portlets on a page, such as HTML. Therefore, do not enable parallel rendering for markups that can only display a single portlet of a page at a time, such as WML. Doing so would trigger additional rendering processes for those portlets which are not displayed and thereby decrease portal performance.
We can change the portal wide settings for parallel portlet rendering in the PortletContainerService. Use two different parameters for configuring parallel portlet rendering, depending on the type of portlets us want to have rendered parallel:

For parallel rendering of local IBM portlets, enable the following parameter:

legacy.useParallelRendering[.markup] = (false)

Activates the portlet container functionality for parallel portlet rendering for the specified markup [false = default, true]. If you omit the markup, the setting applies to all markups for which no specific setting has been defined.

For parallel rendering of local standard portlets, or for remote portlets that you integrated in a WSRP Consumer portal, enable the following parameter:

std.useParallelRendering[.markup] = (false)

Activates the portlet container functionality for parallel portlet rendering for the specified markup [false = default, true]. If you omit the markup, the setting applies to all markups for which no specific setting has been defined.

Settings

false

Parallel rendering is disabled. This is the default. All portlets are rendered sequentially, even if they have parallel rendering enabled.

true

Parallel rendering is enabled. All portlets which have parallel rendering enabled are rendered in parallel. Portlets which do not have parallel rendering enabled are rendered sequentially.

To specify time limits for the parallel rendering process...

parallelRenderingTimeOut = (2000)

Timeout in milliseconds after which the render process of a portlet is aborted.

parallelRenderingWaitTimeOut = (1)

Waiting time in milliseconds for parallel threads to finish the render process of portlets.
A low value can result in exceptions caused by portlets that could not finish their parallel rendering process.
A high value can cause an increase of the portal response time.
The value 0 (zero) specifies that no timeout occurs and the main thread waits for all portlets to finish.

Queues are used to pass the content of the portlet between the threads. The queue parameters are listed here:

parallelRenderingQueueSize = (30720)

Size of the queues in bytes.

parallelRenderingChunkSize = (1024)

Size of the chunks in bytes that are read from the queue.

To improve performance, all queues are held in a pool for reuse. Variations in the usage of the queues result in increase or decrease of the pool size. We can configure the pool size to be more stable by increasing the strength of the hysteresis function. This smoothens how directly the pool size follows the number of accesses. A second property defines the compacting rate, that is how often the pool size is actually reduced as determined by the hysteresis function.

parallelRenderingPoolHysteresis = (10)

Number of accesses to the pool that determines the strength of the hysteresis function. The default is 10.

parallelRenderingPoolCompactRate = (300)

How many seconds the pool size is actually reduced. The default is 300 seconds (= 5 minutes).

Asynchronous beans are used for the parallel rendering process. A WorkManager wm/wpsWorkManager is configured to manage the asynchronous beans. Do not change this name as the name is set in both the WAS and the WebSphere Portal configurations. Set the option isGrowable in the WorkManager panel of the WAS to false. Otherwise parallel portlet rendering might not work to the full extent.
We can further tune parallel rendering by specifying different values for the minimum and maximum number of threads in the WorkManager panel, but the minimum value is 1 (one).
When general tracing is enabled and parallel portlet rendering is turned on, portlets that are configured to be rendered in parallel display the render time as part of the portlet content. To use general tracing but do not want the render times to be displayed for such portlets, selectively disable tracing.

How to prepare portlets for parallel portlet rendering

In general, all portlets must be implemented in a thread-safe manner to be accessible by multiple users at the same time. The portlets can then be rendered in parallel. However, we need to be aware of the following specific limitations for portlets to render in parallel:

In general, do not use any non-public APIs, such as engine tags with portlets. The public APIs are defined in the WebSphere Portal Java documentation. APIs that are not explicitly listed as public APIs are non-public and are not intended for use by custom developed components.

Portlets that are rendered in parallel must not access any non-threadsafe objects that are scoped to the servlet request, such as the servlet request itself:

In general, thread safety of the objects is documented in the Java documentation. Examples of non-threadsafe objects are all unsynchronized Java collections and org.apache.jetspeed.portlet.User.

The portlet request that is passed to portlets that are rendered in parallel is threadsafe and all methods that are part of the portlet API can be safely used. However, the underlying servlet request is not threadsafe.

Portlets that are rendered in parallel, like any other defensively implemented portlets, should be prepared to handle IOExceptions when writing to the OutputStream or PrintWriter of the PortletResponse: Depending on the configuration settings for parallel portlet rendering, if a portlet takes too much time for rendering its content, the portal can cancel rendering this portlet. When the portlet tries to write to the OutputStream or PrintWriter after the portal has canceled the rendering, this results in an IOException. In this case the behavior is the same as if the user closes the browser before the resulting page is delivered to the client. The portlet should take care of proper error handling for this situation.

Portlets that are rendered in parallel should be prepared to abort rendering the content:

In methods that are expected to take many computation cycles, the portlet should check by extended intervals if the flush method of the OutputStream or PrintWriter throws an IOException. If the flush method throws such an exception, the portal has canceled rendering the portlet, and the portlet should terminate its current computation in order to reduce resource usage.

This fault tolerant implementation is useful for various situations in which a response can no longer be delivered to the client. For example, this can happen if the network fails, or the client is closed, or the follow-on page request has already been sent or reloaded. Take care to finalize critical backend operations in order to keep back ends in a consistent state. This processing should be done in the action processing phase and not in the render phase. See the Portlet Development Guide for more info.

As the term Parallel Portlet Rendering indicates, only the rendering phase of a portlet is executed in parallel, not the action phase. Therefore, when you write portlets that are rendered in parallel, follow the Model-View-Controller pattern thoroughly.

Content Access Service
Portlets can access content from remote systems that are located on the other side of a firewall by invoking the Content Access Service. The following settings are used to configure the Content Access Service, but only for those portlets that call this service. We can configure these settings at either of the following locations:

Under the WP PortletServiceRegistryService in the WAS Administrative Console.

In the property file PortletServiceRegistryService.properties under the items beginning with com.ibm.wps.pe.pc.legacy.service.ContentAccessServiceImpl.

com.ibm.wps.pe.pc.legacy.service.ContentAccessServiceImpl.no.proxy.for =

Specifies host names for which ContentAccessServices does not use a proxy, even if a proxy is configured. Values must be separated by semicolon ( ; ). Wildcards are not supported.
Example: com.ibm.wps.pe.pc.legacy.service...no.proxy.for =localhost;127.0.0.1

com.ibm.wps.pe.pc.legacy.service.ContentAccessServiceImpl.protocol.handlers =

Assigns additional URL protocol handlers that Java uses to handle connections to various URL protocols. Values must be separated by a vertical bar ( | ). The default is usually sufficient, as it supplies a handler for https URLs.
Example: com.ibm.wps.pe.pc.legacy.service...ServiceImpl.protocol.handlers = com.ibm.net.ssl.internal.www.protocol

Proxy protocol and port settings
This section allows us to specify proxy protocol and port settings for different protocols. You must specify for each protocol the name and port number of the proxy servers that you use.
The general format is as follows:

com.ibm.wps.pe.pc.legacy.service.ContentAccessServiceImpl.proxy.http.host = hostname

Specifies an HTTP proxy host for http URLs.

com.ibm.wps.pe.pc.legacy.service.ContentAccessServiceImpl.proxy.http.port = port number

Specifies the port for the HTTP proxy. If this is not specified, 80 is used as the default value.

com.ibm.wps.pe.pc.legacy.service.ContentAccessServiceImpl.proxy.https.host

Specifies an HTTP proxy host for https URLs. The proxy must support CONNECT requests, otherwise known as 'tunneling' requests.

com.ibm.wps.pe.pc.legacy.service.ContentAccessServiceImpl.proxy.https.port

Specifies the port for the HTTP proxy. If this is not specified, 80 is used as the default value.

com.ibm.wps.pe.pc.legacy.service.ContentAccessServiceImpl.socks4.host

Specifies a SOCKS V4 proxy host for any URL.

com.ibm.wps.pe.pc.legacy.service.ContentAccessServiceImpl.socks4.port

Specifies the port. If this is not specified, 1080 is used as the default value.

com.ibm.wps.pe.pc.legacy.service.ContentAccessServiceImpl.socks5.host

Specifies a SOCKS V5 proxy host for any URL.

com.ibm.wps.pe.pc.legacy.service.ContentAccessServiceImpl.socks5.port

Specifies the port. If this is not specified, 1080 is used as the default value.

com.ibm.wps.pe.pc.legacy.service.ContentAccessServiceImpl.proxy.auth.enabled

Specifies if authentication should be tried for proxied connections. - This applies to the proxy server, not to the origin server from which the ContentAccessService is fetching. Also, this only applies to HTTP proxy (with settings from proxy.http.* and proxy.https.*) and SOCKS proxy (with settings from proxy.socks4.* and proxy.socks5.*).

com.ibm.wps.pe.pc.legacy.service.ContentAccessServiceImpl.proxy.auth.credentialslot

Specifies if proxy authentication should be used for connections that use a proxy server. You must provide the user ID and password in a credential slot of the portal credential vault. You must also specify the name of this slot in the content access service configuration. The credential must have the type UserPasswordPassive. For details about the credential vault refer to Credential Vault. Proxy authentication applies to the proxy server, not to the origin server from which the ContentAccessService is fetching. Also, this only applies to HTTP proxy (with settings from proxy.http.* and proxy.https.*) and SOCKS proxy (with settings from proxy.socks4.* and proxy.socks5.*).

If no proxy host is set, WebSphere Portal tries to load all URLs directly. If no port is set, the default port for HTTP (80) is used. Alternatively, we can socksify the TCP/IP stack of the system.
Examples:

Name of the http proxy host:

com.ibm.wps.pe.pc.legacy.service...ContentAccessServiceImpl.proxy.http.host = host.somewhere.ibm.com

Name of the http proxy port:

com.ibm.wps.pe.pc.legacy.service.ContentAccessServiceImpl.proxy.http.port = 80

Name of the tunneling https proxy host:

com.ibm.wps.pe.pc.legacy.service.ContentAccessServiceImpl.proxy.https.host = securehost.somewhere.ibm.com

Name of the https proxy port:

com.ibm.wps.pe.pc.legacy.service.ContentAccessServiceImpl.proxy.https.port = 443

Cache Manager Service

The Cache Manager Service is responsible for managing the different caches used in WebSphere Portal Version 6.0. The portal provides two different types of caches: shared and non-shared.

Shared caches

Shared caches are cluster aware. This means that deleting an element from the cache on one cluster node results in deleting that element from the corresponding cache instances on all other nodes. This ensures that frequently changing data are kept consistent over the whole cluster installation.

Non-shared caches

The non-shared caches are used for data where cluster awareness is of no concern. This avoids unnecessary network communication overhead.

Plan well ahead and apply special care when modifying these parameters. There are two levels of parameters:

cacheglobal parameters

Default setting which is to be used for all caches unless explicitly overridden by the corresponding cache instance parameter.

cacheinstance.cacheidentifier parameters

Override a global setting, for example the size of the cache, for a specific instance of a cache.

Change some or all of these settings can dramatically improve or impair portal performance. Therefore IBM recommends not to change the shared setting for any cache unless the consequences are absolutely understood and agreed. To determine the optimal values for the size, lifetime, admit-threshold and replacement parameters, monitor the cache parameters during the staging phase of the portal installation. Use the Tivoli Performance viewer, that is the WAS PMI client to find the optimal settings for the environment.
The parameters for the Cache Manager Service for both shared and non-shared caches are listed in the following:

cacheglobal.enabled = [true|false]

cacheinstance.cacheidentifier.enabled = [true|false]

Controls whether caching is enabled or not. Use this parameter with care !

cacheglobal.size = number

cacheinstance.cacheidentifier.size = number

Number of elements that can be put into the cache before eviction takes place. The eviction uses a "near LRU" algorithm.

cacheglobal.shared = [true|false]

cacheinstance.cacheidentifier.shared = [true|false]

Defines whether a cluster-aware cache is to be used or not.

cacheglobal.lifetime = number

cacheinstance.cacheidentifier.lifetime = number

Lifetime of elements in the cache in seconds. When the specified lifetime is up, elements are not discarded from the cache immediately. They are evicted when the next element is inserted. Specifying -1 means that no timeout is applied.

We can set the following additional parameters for non-shared caches. (Setting them for shared caches does no harm, they will be ignored.)

cacheglobal.replacement= [aggressive | moderate | conservative]

cacheinstance.cacheidentifier.replacement= [aggressive | moderate | conservative]

Controls the eviction algorithm behavior.

cacheglobal.admint-threshold = number

cacheinstance.cacheidentifier.admint-threshold = number

Admittance threshold. Keep unwanted entries from the cache. An entry is cached only if it is put into the cache as often as specified by the value for this parameter. If you want each entry to be cached, set this parameter to zero ( 0 ).

State Manager Service

The State Manager Service is the access point for managing the navigational state of the portal. The navigational state represents the current view of portal resources as displayed to a user.

preprocessors = (com.ibm.wps.state.preprocessors.selection.StandardPortalSelectionImpl )

List of one or more preprocessors that are used. Note that for requests the preprocessors are processed in the sequence in which you arrange them here. The required syntax is (classname (, classname) * ) 1 .
If you specify a value for this parameter, that value overwrites the default value. The default value is as follows:
preprocessors = com.ibm.wps.state.preprocessors.selection.StandardPortalSelectionImpl
WebSphere Portal Version 6.0 provides the following two selection preprocessors. They process the page selected by the user.
Both of these selection preprocessors are exclusive. This means that they cannot be used in combination with each other.

com.ibm.wps.state.preprocessors.selection.StandardPortalSelectionImpl

This value implements the standard portal selection behavior which prefers displaying pages over displaying labels. This means that if a user selects a label, the portal displays a page under that label, rather than the label itself with the message saying that there is no content available. (In this case the page displayed is the last page that the user selected under this label, or if that page is not available, the first available page below the label.)

com.ibm.wps.state.preprocessors.selection.SimpleSelectionImpl

This value implements a simple selection strategy; it always displays the element selected by the user, regardless of whether the user selects a label or a page. If the user selects a label, the portal displays that label with the message that there is no content available.

keymanager.lru.size = ( integer )

History expiration limit of portal pages visited by users. This determines how far backwards users can at least navigate in the recent history of portal pages that they visited. The number that you specify defines the minimum number of different pages selected by the user after which the portal can discard the render parameters of a page. (The decision whether the render parameters of the page are actually discarded depends on the expiration policy of the internal cache that stores the render parameters of those pages.) If the user returns to a page after visiting the specified number of other pages and if the render parameters of that page have expired, the portal displays that page in its default state. For details about the portal navigational behavior refer to Portal navigation and browser Back button behavior.
We can specify by which circumstances the render parameters of a page are stored or discarded:

1

Each time that the user selects a different page, the render parameters of the portlets on the previously selected page can be discarded.

A positive integer

Required number of pages. The render parameters of a given page can be discarded after the user has visited that number of other pages.

0

Render parameters are always stored in the portal session memory and never discarded.

Do not specify a value below zero ( 0 ). Negative values are considered to be not valid.

URL normalization for search of portal pages by external search engines

The following parameter is used to configure the normalization of the URL of the portal. URL normalization is required to enable external search engines to crawl the content of the portal. For this purpose URL normalization performs the following:

It removes all elements from a portal page URL that are used for portal internal purposes. For example, these are actions, which are coded into the URL and change the portal state.

It reduces the portal page URL to those elements that are required for a crawler to read the URL and crawl the portal page.

com.ibm.wps.state.outputmediators.OutputMediatorFactory.normalization_xsl_file = ( UrlNormalization_MIN.xsl )

XSL stylesheet file that defines the transformation that should be used in order to normalize the portal URL. The default value is UrlNormalization_MIN.xsl. The following two files are available to allow for a minimum or maximum transformation:

UrlNormalization_MIN.xsl

This XSL stylesheet contains the states for portlet-mode, window-state, renderparameters, selection, and locale in the normalized URL. This transformation represents the minimum set of states that have to be defined in the URL. All other states are removed from the URL. This value is the default.

UrlNormalization_MAX.xsl

This XSL stylesheet contains the states for portlet-mode, window-state, renderparameters, selection, solo, locale, and screen-template. This maximum transformation represents the set of states that can be defined in a normalized URL for a Web crawler. All other states are removed from the URL.

The meaning of the different states listed for the minimum and maximum normalization stylesheets is as follows:

portlet-mode

Portlet modes allow a portlet to display a different user interface, depending on the task that the user performs with the portlet. A portlet has five modes of display: view, help, edit, edit_defaults, config.

window-state

Portlet states allow users to change how the portlet window is displayed within the portal. Users can choose from three different states: maximized, minimized, normal.

renderparameters

Parameters set to render a portal page.

selection

Selected portal page.

solo

A portlet can also be displayed in solo state. Solo state hides the portal theme elements, such as a banner, page navigation, or tool bar.

locale

Language in which the page is presented.

screen-template

Screen that is used on the portal page.

theme-template

Theme that is used on the portal page.

We can also set up your own URL normalization. To implement a URL normalization that is different than those provided by the two XSL stylesheets that come with the portal, create your own XSL stylesheet and set it as the value for the URL normalization parameter:

Here is an example for creating your own XSL stylesheet:
<?xml version="1.0" encoding="UTF-8"?> <xsl:stylesheet version="1.0" xmlns:xsl="http://www.w3.org/1999/XSL/Transform"> <xsl:output method="xml" version="1.0" encoding="UTF-8" indent="yes"/> <xsl:template match="text()"> </xsl:template>  <xsl:template match="root"> <xsl:copy> <xsl:copy-of select="@*"/>  <xsl:apply-templates select="state[@type='navigational']"/> </xsl:copy> </xsl:template>   <xsl:template match="state"> <xsl:copy> <xsl:copy-of select="@*"/> <xsl:apply-templates select="... "/> ... </xsl:copy> </xsl:template> ... ... ... </xsl:stylesheet>

Set the name of the new XSL stylesheet as the value for the URL normalization parameter:
com.ibm.wps.state.outputmediators.OutputMediatorFactory.normalization_xsl_file = UrlNormalization_Your_Own_Style_Sheet_File_Name.xsl

Administrator Unique Names Mapping Service
Administration portlets and themes create URL links to other administration portlets and pages. If these links were hardcoded, they would no longer be usable if you changed the unique names of these pages. Therefore a service for obtaining those unique names is provided in the AdminUniqueNamesMappingService. This file contains key-value pairs mapping internal keys to the actual unique names which are assigned to the referenced pages.
If you change the unique name of a portal administration page using the Manage Unique Names portlet, you also need to update that name in the properties. This is required so that the theme and administration portlets still function. The available mappings are defined as follows:
# ----------------------------------------------- # # Portal administration page unique names mapping # # ----------------------------------------------- # # Internal key unique name # # ----------------------------------------------- # # #CONTENT_LAYOUT = ibm.portal.Content #APPEARANCES = ibm.portal.Appearance #MANAGE_PAGES = ibm.portal.Manage Pages #UNIQUE_NAMES = ibm.portal.Custom Unique Names #ASSIGN_ROLES = ibm.portal.Resource Permissions #PROPERTIES_PORTLET = ibm.portal.Page Properties #MY_FAVORITES = wps.My Favorites #ORGANIZE_FAVORITES = wps.Organize Favorites #SET_PERMISSIONS = ibm.portal.Locks #MANAGE_LOG = ibm.portal.Enable Tracing #MY_PORTAL = ibm.portal.Home #ADMINISTRATION = ibm.portal.Administration #PAGE_CUSTOMIZER = ibm.portal.Page Customizer #PORTLET_MANAGER = ibm.portal.Web Modules #MANAGE_MY_PORTLETS = ibm.portal.Portlets #MANAGE_MY_PORTLET_APPS = ibm.portal.Applications #MANAGE_WEBSERVICES = ibm.portal.Web Services #IMPORTXML = ibm.portal.Import XML #SEARCH_CENTER = ibm.portal.Search Center #VIRTUAL_PORTAL = ibm.portal.Virtual Portal #LOGIN = wps.Login #SELFCARE = wps.Selfcare #APP_PROPERTIES = ibm.portal.Template and Application Properties #APP_PARAMETER = ibm.portal.Template Parameters #APP_ROLES = ibm.portal.Application Roles #APP_TEMPLATES = ibm.portal.Templates #APP_MEMBERSHIP = ibm.portal.Application Membership #APP_CATALOG = ibm.portal.Catalog #APP_LAYOUT = ibm.portal.Template and Application Layout #PZN_PICKER_PAGE = ibm.portal.Personalization.Picker

Examples of where these unique names are used are: Theme links for 'New Page', 'Edit Page', and 'Assign Permissions'.

Portal Security Services

The following sections describe the different configuration services provided for Portal Access Control and authentication.

Access Control Data Management Service

The Access Control Data Management Service contains the configuration settings for Portal Access Control. The domain short names have to correspond to the domain names that are defined for the DataStore Service. The following set of properties is mandatory for each database domain that contains resources that need to be protected by Portal Access Control:

accessControlDataManagement.domain.domain_short_name.adminuser = full DN of the administrative user for this domain

Define the administrative user. As the value specify a full DN that corresponds to a valid entry in the associated user repository. Mandatory.

accessControlDataManagement.domain.domain_short_name.admingroup = full DN of the administrative group for this domain

Define the administrative group. As the value specify a full DN that corresponds to a valid entry in the associated user repository. Mandatory.

accessControlDataManagement.domain.domain_short_name.virtualresource = name of the virtual root resource of this domain

Virtual root resource. The value is the name of a virtual resource that actually exists in the domain and represents the root of the protected resource hierarchy in this domain. This property is meant for internal use only; do not change its value.

The administrative user and group are granted administrator roles on the full hierarchy of protected resources starting from the virtual root resource of the domain defined with the third setting. These roles are granted in addition to the portal roles of the user or group and therefore not displayed in the Access Control portlets. A valid set of values to these properties could for example look like the following:
accessControlDataManagement.domain.rel.adminuser=uid=Bob,o=Our Company accessControlDataManagement.domain.rel.admingroup=cn=Admins,o=Our Company accessControlDataManagement.domain.rel.virtualresource=PORTAL accessControlDataManagement.domain.cust.adminuser=uid=Bob,o=Our Company accessControlDataManagement.domain.cust.admingroup=cn=Admins,o=Our Company accessControlDataManagement.domain.cust.virtualresource=PORTAL accessControlDataManagement.domain.comm.adminuser=uid=Bob,o=Our Company accessControlDataManagement.domain.comm.admingroup=cn=Admins,o=Our Company accessControlDataManagement.domain.comm.virtualresource=PORTAL accessControlDataManagement.domain.jcr.adminuser=uid=Bob,o=Our Company accessControlDataManagement.domain.jcr.admingroup=cn=Admins,o=Our Company accessControlDataManagement.domain.jcr.virtualresource=PORTAL
The following additional properties of the Access Control Data Management Service are optional:

accessControlDataManagement.enableNestedGroups = (true)

Whether the group membership of groups is exploited at all by the Portal Access Control component. Supported values are: true and false. The default is true.

accessControlDataManagement.enableTargetResourceGroupInheritance = (false)

Whether the group membership of groups is exploited by the Portal Access Control component for permission enforcement on users or groups. If you specify false, we can only get permissions on user groups via roles on the groups and on users via roles on the direct groups of which the user is a member. Supported values are: true and false. The default is false.

accessControlDataManagement.reorderRoleNames = (false)

Determine whether the role name contains the unique name or the title of the resource on which the role was created. Specify true when you use an external authorization provider, such as IBM Tivoli Access Manager for e-business, as this makes it easier to find the role names. Supported values are: true and false. The default is false.

accessControlDataManagement.externalizeAllRoles = (false)

Applicable only for externalization of resources through the user interface. The default value is false. If the property is set to false and a resource is externalized, then the following things happen:

The resource and all descendants of this resource that are not private and not externalized so far are externalized.

The roles and role mappings that exist on all resources that were identified in the previous step 1 are written into the external security manager object space.

For the root resource that was chosen to be externalized, a role mapping for the Administrator role for the executing user is created in the external security manager object space.

If this property is set to true, then in addition to the three steps above, roles are created in the external security manager object space for all action sets for the root resource that have not already been created in steps 2 and 3. above.

accessControlDataManagement.createAdminMappingXMLAccess = (true)

Applicable only for externalization of resources through the XML Configuration Interface. If the property is set to false and a resource is externalized the following happens:

The resource will be externalized.

The roles and role mappings on the resource are written into the external security manager object space.

If the property is set to true, then in addition to the two steps above, a role mapping for the Administrator role is created for the executing user in the external security manager object space.

Connecting to the user repository during startup: Change the following two settings if you want the portal to wait and retry connecting to the underlying user repository, if it is not available during portal startup. This might be necessary in scenarios where the user repository is only available in a certain time frame after the initialization of the portal startup. As the domain administrative users and groups have to be resolved, the portal cannot start without connecting to the user repository. The service startup performs the specified number of attempts to connect to the user repository, each time waiting for the specified time interval before starting the next attempt. If none of the attempts is successful, the service startup quits with an exception.

accessControlDataManagement.ldapFailoverNumberOfAttempts = ( 1 )

Hany times the service startup attempts to connect to the user repository. The default is 1 (once).

accessControlDataManagement.ldapFailoverInterval = ( 60 )

How long the service startup waits until it retries to connect to the user repository. This value is specified in seconds. The default is 60 seconds.

Authentication Service

The Authentication Service contains the configuration settings for portal authentication. Authentication means that users identify themselves in order to gain access to the system. Usually they do this by a user ID and password.

authentication.execute.portal.jaas.login = (false)

Enable or disable the execution of the portal JAAS login:

false

Disable the execution of the portal JAAS login. This is the default. Disable this property only if you have no JAAS Login Modules defined for the portal application login configuration.

true

Enable the execution of the portal JAAS login. We can enable this property if you have JAAS Login Modules defined for the portal application login configuration.

This is related to performance.

authentication.screen.login = (false)

Determine whether an error during authentication results in a redirect to an error screen or if an exception is thrown that can be caught by the Login portlet.

false

Means an error condition during authentication results in an exception that is caught by the Login portlet. This is the default.

true

Means an error condition during authentication results is redirected to an error screen.

Credential Vault Service

Use the Vault Service configuration to specify Vault Adapter implementations that are used by the Credential Vault Service to store credential secrets. By default two Vault Adapter implementations are available: default-release and default-customization. Those Vault Adapters store credential secrets in the portal server datastore. For each implementation, define a unique string type, a class name, and a domain. Optionally, we can specify a configuration file, managing resources, and a read only flag. We can define the following properties for each Vault Adapter Implementation Type. In order to differentiate the settings for each type, the properties are in the format vault.type.key. Replace type by the Vault Adapter Implementation Type, and replace key by the key. The following list shows the keys that we can append:

class

Vault Adapter Implementation Class Name, but without the.class extension. This parameter is mandatory.

config

Path of a configuration file that the adapter may need. Optional.

domain = (rel)

Database domain where the segment and slot configuration data is stored. In the special case of the DefaultVault, this also specifies where the actual credentials are stored. This parameter is mandatory. Possible values are all available database domains as specified in the DataStore Service. The default value is rel; this specifies the release domain.

manageresources = (false)

Whether the VaultAdapter should create and delete resources. Optional.
If set to true, the adapter must have internal support to manage resources. If you omit this parameter, it will default to false.

readonly = (true)

Whether the underlying vault for this adapter should be considered read only. Optional.
If you set this parameter to true, the manageresources parameter is ignored. If you omit this parameter, it will default to true.

Additionally, we can specify the Distinguished name (DN) of the vault administrative user. All system credentials will be stored under the account of this user:

systemcred.dn

This key is set to the portal administrative user by default.

External Access Control Service

The External Access Control Service is responsible for collecting any authorization data from external security managers, such as Computer Associates eTrust SiteMinder, or IBM Tivoli Access Manager for e-business. These are the parameters set by the configuration of external security managers procedures. For some of the parameters listed here a more detailed explanation is given under Configuration properties reference.
The following configuration parameters can be modified in External Access Control Service. However, plan well ahead and apply special care when modifying these parameters.

General properties of the External Access Control Service:

These properties are used for general purposes of the External Access Control Service.

externalaccesscontrol.ready = (false)

Connect to the External Security Manager. The default is false.

externalaccesscontrol.server = WebSphere_Portal

externalaccesscontrol.application = WPS

externalaccesscontrol.cell = cell

Role name representations are qualified with a context built by these three parameters. For example, the Administrator@External_Access_Control/xxx/xxx is represented as follows:

Tivoli Access Manager: Protected object space entry

/WPSv6/Administrator@External_Access_Control/xxx/xxx/WPS/WebSphere_Portal/cell

eTrust SiteMinder:

resource/subrealms under Domain: WebSphere Portal v5
/cell/WebSphere_Portal/WPS/Administrator@External_Access_Control/xxx/xxx

Access Manager configuration:

Use the following properties to configure the connection between WebSphere Portal and the Tivoli Access Manager.

externalaccesscontrol.pdroot = (/WPSv6)

After you completed the AMJRTE and SrvSslCfg configuration tasks, the following directives are required to allow WebSphere Portal to use Tivoli Access Manager as an External Security Manager. Provide the root of the Protected Object Space for Portal Server entries.

externalaccesscontrol.pduser = sec_master
externalaccesscontrol.pdpw = passw0rd

Provide an administrative user ID and password with adequate rights in Tivoli to create, delete, modify the objects in the Protected Object Space.
Use the WAS PropFilePasswordEncoder utility to mask the password. Using PropFilePasswordEncoder will remove any comments and uncommented properties. Therefore create a backup copy of this file for future reference. Example:
app_server_root/bin/PropFilePasswordEncoder portal_server_root/config/properties/ExternalAccessControlService.properties externalaccesscontrol.pdpw

externalaccesscontrol.pdurl=file:///${WAS_INSTALL_ROOT}/java/jre/PdPerm.properties

URL location of the Access Manager properties file for AMJRTE. This URL must be in the format file:///directory_path_to_properties_file. HTTP URLs are not supported.

externalaccesscontrol.createAcl = (true)

Optional. Specify whether Access Control Lists (ACLs) are created in Access Manager for roles that are stored externally. The default is true. If this parameter is set to false, the Access Manager administrator will be responsible for all ACL linkages between Tivoli Access Manager and WebSphere Portal. Possible values for this parameter are:

true

A Tivoli Access Manager ACL will be created for every WebSphere Portal resource. This is the default.

false

No ACLs will be created for portal objects.

externalaccesscontrol.pdactiongroup = ([WPS])

externalaccesscontrol.pdAction = (m)

These parameters are optional. Use these parameters to specify the action group and the customized actions to map to portal role membership. If these items do not exist, they will be created at startup. The values given above are the default values.

Computer Associates eTrust SiteMinder Policy Server information:

Use the following properties to configure the connection between WebSphere Portal and the Policy Server.

externalaccesscontrol.domainname = WebSphere Portal V 6

Domain name that is to be created in the eTrust SiteMinder administrative GUI. All realms and sub-realms will be created under this domain. This domain will be created when starting WebSphere Portal.

externalaccesscontrol.scheme = (Basic)

Scheme that is to be to associated with the realms. You must define this scheme in eTrust SiteMinder before starting WebSphere Portal. The default value is Basic.

externalaccesscontrol.agentname = wpsagent

externalaccesscontrol.agentsecret = passw0rd

Use these parameters to specify the agent name and secret to establish a runtime connection with eTrust SiteMinder. The agent should be a Web agent with a static shared secret, so that Web Agents later than V4.6 of WebAgents should enable the parameter supports 4.x agents on the eTrust SiteMinder WebAgent. Use the WAS PropFilePasswordEncoder utility to mask the password.
Using PropFilePasswordEncoder removes all comments and all properties that are commented out. Therefore make sure you create a backup copy of this file for future reference before using the PropFilePasswordEncoder utility.
An example of masking the password is:
app_server_root/bin/PropFilePasswordEncoder portal_server_root/shared/app/config/properties/ExternalAccessControlService.properties externalaccesscontrol.agentsecret

externalaccesscontrol.admin = siteminder

externalaccesscontrol.password = passw0rd

Use these parameters to specify the administrative user ID and password for a user who can create, delete, and modify eTrust SiteMinder objects that are used to represent WebSphere Portal roles. This user ID must have sufficient access to domain level objects in eTrust SiteMinder.
Use the WAS PropFilePasswordEncoder utility to mask the password. Using PropFilePasswordEncoder removes all comments and all properties that are commented out. Therefore make sure you create a backup copy of this file for future reference before using the PropFilePasswordEncoder utility.
An example of masking the password is:
app_server_root/bin/PropFilePasswordEncoder portal_server_root/shared/app/config/properties/ExternalAccessControlService.properties externalaccesscontrol.password
externalaccesscontrol.userdir = (User Directory 1)

User Directory that is associated with the domain. We can configure the failover for user directories in the eTrust SiteMinder administrative GUI. The user directory must exist before you start WebSphere Portal.

externalaccesscontrol.failOver = (false)

Whether the ESM subsystem should switch to another Policy Server if it cannot contact the current one. Possible values are true and false. We can specify this property as either...
exteralaccesscontrol.failOver

...as...
exteralaccesscontrol.failover

It is important that this value and the number of Policy Server IP addresses that are specified by the servers property are carefully coordinated. If you specify multiple Policy Server addresses on the servers property, and this property is set to false, then the Computer Associate's Agent API will follow round-robin load balancing, by distributing or spraying requests between the configured Policy Servers. This may be appropriate for a TAI which is only doing read operations from the Policy Server(s), but not for write operations . If you have multiple servers defined in the externalaccesscontrol.servers property (following next), set failOver to true.

externalaccesscontrol.servers = server1,server2,...

IP addresses of all the Policy Servers. Multiple addresses need to separated by commas. An example is: servers=10.0.0.1,10.0.0.2 .
If you have multiple servers defined in the externalaccesscontrol.servers property, set the failOver property to true. We can define the following properties for each server. In order to differentiate the settings for each server, specify the keys in the format Server IP address.key=value. The defaults are assumed for any keys that you omit. The available keys are as follows:

accountingPort = (44441)

Accounting port for the Policy Server. The default is 44441.

authenticationPort = (44442)

Authentication port for the Policy Server. The default is 44442.

authorizationPort = (44443)

Authorization port for the Policy Server. The default is 44442.

connectionMax = (10)

Maximum number of connections which the authorization service may make to this Policy Server. The default is 10.

connectionMin = (1)

The initial number of connections which the authorization service will establish with this Policy Server. The default is 1.

connectionStep = (1)

The number of connections that are to be allocated if the authorization service runs out of connections to the Policy Server. The default is 1.

timeout = (20)

Connection timeout in seconds. The default is 20.

An example for server 10.0.0.1 is as follows:
10.0.0.1.accountingPort=44441 10.0.0.1.authenticationPort=44442 10.0.0.1.authorizationPort=44443 10.0.0.1.connectionMax=30 10.0.0.1.connectionMin=10 10.0.0.1.connectionStep=5 10.0.0.1.timeout=60

Auditing Service

The auditing service allows one to log a set of events into a separate audit log file. All events are organized in groups. For example, the logging events User created and User deleted are grouped together and can therefore only be switched on or off together.
The audit logging output is written to the audit log file. No other log messages are written to this file.

Auditing service configuration

By default the audit logging service is disabled. This means that the service is loaded, but does not register any event listeners for audit logging. The auditing service configuration is controlled by the AuditService.

audit.service.enable = (false)

Global switch. Use it to switch the service on (true) or off (false). The default setting is false.

The actual log file access of the service can be configured by using the following two properties:

audit.logging.class = com.ibm.wps.audit.logging.impl.AuditLoggingImpl

This property points to the logging class which writes the actual log statements to the log file. By default, this is set to the default implementation. Under normal circumstances there is no reason to replace it with another class.

audit.logFileName = log/audit_$create_time.log

Location and the name of the audit log file. The placeholder $create_time is replaced by a timestamp during filename generation. A second placeholder $APPSERVER_NAME is used for a vertical cluster configurations to make the log file name unique. Example:
audit.logFileName = log/audit_$APPSERVER_NAME_$CREATE_TIME.log

The auditing service allows us to have the transaction ID written to the audit log file. As these transaction IDs can be very long and might not be required in every environment, we can disable the inclusion of the IDs.

audit.showTransactionID.enable = (true)

Disable transaction IDs in the audit log. To do this, change the value to false. The default value is true.

You determine the events that you want to be logged by enabling the appropriate properties as required. Set the events that you want to enable to the value true. The following groups of events are defined:
audit.groupEvents.enable audit.userEvents.enable audit.portletEvents.enable audit.roleEvents.enable audit.roleBlockEvents.enable audit.ownerEvents.enable audit.resourceEvents.enable audit.externalizationEvents.enable audit.userInGroupEvents.enable audit.webModuleEvents.enable audit.applicationRoleEvents.enable audit.principalToApplicationRoleMappingEvents.enable audit.roleToApplicationRoleMappingEvents.enable

The default value for all of these settings is false. That means that no events will be logged by default, even if you have switched the service on by setting the property audit.service.enable to true. For more details about which events are included in each group refer to Available events.
To enable one or more groups of events, change the default value of the appropriate audit.eventGroup.enable property to true.

Audit log file

The log file contains one audit log message per line. All log messages start with a timestamp, followed by the optional transaction ID, the message code and the event message. Each event message contains the following:

The user ID of the user who has performed the action which triggered the audit event

Additional information about the event itself.

Events for actions that run in a transaction are written to the log file when the transaction s committed. If the transaction is rolled back, no event messages are written to the log file.
Events for actions that do not run in a transaction are written to the log immediately. In such cases it is not guaranteed that the related action was completed successfully.

Available events

This section lists the events that we can log by using the auditing service. They are listed by the groups in which they are available. If you enable one group, all events in that group are logged.

Audit logging group Audit logging event Description
audit.groupEvents Group created A new user group has been created via portal UIs.
Group modified A user group has been modified via portal UIs.
Group deleted A user group has been deleted via portal UIs.
audit.userEvents User created A new user has been created via portal UIs.
User modified A user has been modified via portal UIs.
User deleted A user has been deleted via portal UIs.
audit.portletEvents Portlet Application created A new Web module or portlet application has been created via portal UIs.
Portlet Application modified A Web module or portlet application has been modified via portal UIs.
Portlet Application deleted A Web module or portlet application has been deleted via portal UIs.
audit.roleEvents Role assigned A portal role has been assigned to a user. The user has been given the specified type of access permission on all resources that are affected by this role. For example, this can be EDITOR on Page1.
Role unassigned A portal role has been unassigned from a user. The user no longer has the specified access rights on the resources that are affected by this role. For example, the user is no longer EDITOR on Page1.
audit.roleBlockEvents Role block modified The portal role block information of a resource has been changed. The event message contains a list of blocked and non-blocked roles on the given resource. As roles can either be inherited or propagated, there are two seperate lists for inheriting roles and propagating roles. If only propagating role blocks have been changed, the list for inheriting roles is empty and vice versa.
audit.ownerEvents Resource owner modified The owner of a resource has been changed.
audit.resourceEvents Resource created A new resource has been registered. This event is triggered when the resource is registered in Portal Access Control.
Resource modified A registered resource has been modified.
Resource deleted A registered resource is no longer registered in Portal Access Control. This usually happens when a resource is deleted.
audit.externalizationEvents Resource externalized A resource has been externalized. This means that access permissions to this resource are no longer controlled by Portal Access Control, but by an external Access Manager. For example, this can be Tivoli Access Manager.
Resource internalized A resource has been internalized. It is now controlled by Portal Access Control and no longer by an external Access Manager.
audit.userInGroupEvents User added to group A user has been added to a group. The user is now a member of this group and therefore inherits access rights from the group.
User removed from group A user has been removed from a group. The user is no longer a member of that group and does no longer have the inherited access rights.
audit.webModuleEvents Web Module installed A new Web module has been installed or deployed.
Web Module uninstalled An installed Web module has been uninstalled.
audit.applicationRoleEvents Application role created An application role has been created.
Application role deleted An application role has been deleted.
audit.principalToApplicationRoleMappingEvents Application role assigned An application role has been assigned to a user. The user has been given the access permissions contained in all the roles that are aggregated in this application role.
Application role unassigned An application role has been unassigned from a user. The user no longer has the access permissions contained in all the roles that are aggregated in this application role.
audit.roleToApplicationRoleMappingEvents Role added to application role A portal role has been added to an application role. All permissions contained in the portal role are added to the application role. Effective immediately, these added permissions are given to all users or groups to whom the application role is currently assigned.
Role removed from application role A portal role has been removed from an application role. The users who had this application role no longer have the access permissions that are contained by this role.
audit.domainAdminDataEvents.enable Domain administration data initialized The administrative data for a domain, such as administrative user, administrative group, and virtual root resource, has been initialized during the startup of the portal. For the lifetime of the current portal process, this user and group have administrative permissions on the domain resource hierarchy, starting from the virtual root resource. For details about this refer to Access Control Data Management Service. This event is always thrown for each defined domain during server startup. As this is done by the system, no performing user will be logged.

Puma and Puma Validation services

The following sections list and describe the configuration services for Puma: the Puma service and the Puma Validation service.

Puma service

The Puma service contains the configuration settings for Portal User Management.

user.fbadefault.filter =

Default search attribute for users.
Usually this is the same as the Relative Distinguished Name (RDN) attribute of the LDAP. Depending on the environment, it might be a different attribute. The default is set to the same value as that of the LDAPUserPrefix in the file wpconfig.properties.

group.fbadefault.filter =

Default search attribute for groups.
Usually this is the same as the RDN attribute of the LDAP. Depending on the environment, it might be a different attribute. The default is set to the same value as that of the LDAPGroupPrefix in the file wpconfig.properties.

user.base.attributes =

Attribute subset that portal loads during direct user lookups, for example at Login.
Attributes that are not defined in this list are loaded by a separate request to the backend user store.

user.minimum.attributes =

Attribute subset that portal loads during attribute searches for users. Attributes that are not defined in this list are loaded by a separate request to the backend user store.

group.minimum.attributes =

Attribute subset that portal loads during attribute searches for groups. Attributes that are not defined in this list are loaded by a separate request to the backend user store.

user.sync.remove.attributes = (disabled)

Defines user attributes that are not stored in the backend user store.
Set attributes that you want to keep available only for one session. Consequently, we cannot use portal user management to persist such an entry beyond the session. The default for this property is disabled.

group.sync.remove.attributes = (disabled)

Defines group attributes which are not supposed to be stored in the backend user store. The default for this property is disabled.

userManagement.cacheMode = (true)

Defines whether Puma uses a cache or not. The default for this property is true.

puma.commonname = ( {0} {1} )

Portal User Management can generate the common name (CN) of a user automatically.
Defines how the CN is generated. We can define dynamic and static parts. Dynamic parts are added by using {X}, where X stands as a reference number to the puma.commonname.X that defines the attribute that you want to place here. Dynamic parts can only be user attributes that are available and valid. The default is {0} {1}.

puma.commonname.parts =

Number of dynamic parts in the common name.

puma.commonname.X =

The user attribute for dynamic part X. X must be between 0 and puma.commonname.parts -1. The default is puma.commonname.0 = givenname and puma.commonname.1 = sn.

Puma Validation service

The PUMA Validation Service contains the configuration settings for the Validation component of PUMA.
Properties for user validation

user.YOURATTRIBUTE.max = (60)

Maximum number of characters that is allowed for the defined YOURATTRIBUTE. The default is 60.

user.YOURATTRIBUTE.min = (1)

Minimum number of characters that is allowed for the defined YOURATTRIBUTE. The default is 1.

user.YOURATTRIBUTE.charset = (ascii)

Character set against which characters are validated. Supported values are ascii and unicode. The default is ascii.

user.YOURATTRIBUTE.extra_chars = ( -._ )

Defines extra special characters which are not in the supported character set, but should be treated as valid. By default, the dash, period, and underscore are valid: -._

Notes:

The YOURATTRIBUTE portion of the property needs to be spelt in uppercase.

The sets of attributes listed in the following sections follow the same pattern as the one above.

Settings for the attribute user.fbadefault.filter defined in Puma service :

user.UNIQUEID =

For this property specify the value of the user.fbadefault.filter attribute that is defined in the Puma service.

user.UNIQUEID.min = 1

user.UNIQUEID.max = 60

user.UNIQUEID.charset = ascii

user.UNIQUEID.extra_chars = -._

Properties for group validation:

group.RDN=

For this property specify the value of the group.fbadefault.filter attribute that is defined in the Puma service.

group.extra = -,_

group.RDN.min = 1

group.RDN.max = 200

Properties for password validation:

password.min_characters = 5

password.max_characters = 60

password.charset = ascii

password.extra_chars = -._

The XML configuration interface

For hints on how to export a configuration from an existing portal and import it to another portal, refer to the The XML configuration interface.

Related information

Overview of portal configuration services
Setting configuration properties
Persistent session state (session hibernation)
Portlet filters
URL Mapping
Portal configuration
The XML configuration interface
Portal configuration
Installing databases
Transferring all domains
Transferring DB2 for iSeries manually
Administering
Portlet development basics
Customizing the portal
Developing portlets
Tuning
Credential Vault

Parent topic:
Portal service configuration

0	Disabled	Portlet Menus are not displayed in the navigation menu at all.
1	Current selection	Only the portlet menus of the portlets that reside on the currently selected page are added below the navigation menu item for that page. This is the default value.
2	Everything	The portlet menus of all portlets on all pages are added below the appropriate navigation menu items in the navigation tree.

Portal resource	Standard API portlet application	IBM API portlet application
Portlet Application	Default locale	N/A
	Title	Title
	User attributes	Context parameter
Portlet	Name	Name
	Title	Title
	Short title	Short title
	Keywords	Keywords
	Description	Description
	Default locale and description	Default locale
	Initialization parameter	Initialization parameter
	Preferences	N/A
	Remote cache settings	Cache settings
	Expiration date settings	N/A
Servlet	N/A	Mappings

1	Never discard the workspace.
0	Always discard the workspace immediately after the action that required the workspace has been completed.
> 0	Time interval (in minutes) for which a workspace is retained before it is discarded. It is then rebuilt for the next deployment task.

DBMS used	DBMS value for xxx.datasource.dbms properties
IBM Cloudscape	CLOUDSCAPE
IBM DB2 Universal Database Enterprise Server Edition	DB2
IBM DB2 Universal Database for iSeries	DB2_ISERIES
IBM DB2 Universal Database for z/OS	DB2_ZOS
Oracle Enterprise Edition	ORACLE
Microsoft SQL Server Enterprise Edition	SQLSERVER

Key	Meaning	Default value
public.session	Specifies whether an anonymous user always has a public.session. This may be useful when a portlet requires a session for anonymous users. To enable public sessions for pages that anonymous users can view without logging in, set this parameter to true. The setting of public.session influences the remote cache scope for public pages. If public.session is set to true, then the cache scope is set to non-shared (private). If public.session is set to false, then the cache scope is set to shared (public). Setting public.session to true reduces portal performance.	false
public.expires	Specifies the cache expiration time (in seconds) for caches outside of the portal and for unauthenticated pages only. These caches must adhere to the HTTP 1.1 specification (RFC 2616). The public.expires key specifies the time after which HTTP caches should drop the response. This can be further restricted by the remote.cache.expiration key (see below). This value is used as a maximum value for the cache expiration time and as a global default value for unauthenticated pages. If the setting remote.cache.expiration is also set to a value greater than or equal to 0, the smaller one of the two values is used. The portal calculates and aggregates the remote cache information, that is the scope and expiration time, by a number of parameters contributed by themes, pages, and portlets besides the settings described here. Therefore the portal can do any of the following internally while processing a request: Reduce the cache lifetime Reduce the cache scope, for example, from public (shared) to private (non-shared) Switch off the overall cachability of pages. Therefore this value might not be static for all responses resulting from requests to unauthenticated pages. The response of the portal sets the following header fields: The Expires header with the expiration time added to the system date and time of the portal The Cache-Control : max-age = header with the expiration time as its parameter. The default setting specified in this file is 60 seconds. If no value is specified, the portal defaults the value to 60 seconds.	60
remote.cache.expiration	Specifies the maximum cache lifetime (in seconds) of a page, both public and private. Use this setting to specify a global value for the expiration of pages in remote caches. Setting this value to 0 switches caching off in remote caches. If the legacy setting is not available, this setting is used for authenticated and unauthenticated pages. If the legacy setting is available, then the smaller of the two values is used for unauthenticated pages only. In this case the remote.cache.expiration setting is used for authenticated pages in general. If theme, composition, and portlets contribute remote cache information, then the global settings also contribute to the information. In this case the lowest of the values of all contributors is used, including the global settings. The default setting specified in this file is 60 seconds. If no value is specified, the portal defaults the value to zero (0 seconds).	0
remoteCacheInfo.response.header.vary	Specifies the HTTP headers that force a proxy to cache different variants of the same URL. Use this setting to specify a comma separated list of HTTP header fields to which the portal should refer in its vary field of the generated HTTP response. This is required to ensure that proxy caches can invalidate entries in their cache if the specified header fields do not match from request to request.	User-Agent

Audit logging group	Audit logging event	Description
audit.groupEvents	Group created	A new user group has been created via portal UIs.
	Group modified	A user group has been modified via portal UIs.
	Group deleted	A user group has been deleted via portal UIs.
audit.userEvents	User created	A new user has been created via portal UIs.
	User modified	A user has been modified via portal UIs.
	User deleted	A user has been deleted via portal UIs.
audit.portletEvents	Portlet Application created	A new Web module or portlet application has been created via portal UIs.
	Portlet Application modified	A Web module or portlet application has been modified via portal UIs.
	Portlet Application deleted	A Web module or portlet application has been deleted via portal UIs.
audit.roleEvents	Role assigned	A portal role has been assigned to a user. The user has been given the specified type of access permission on all resources that are affected by this role. For example, this can be EDITOR on Page1.
audit.roleEvents	Role unassigned	A portal role has been unassigned from a user. The user no longer has the specified access rights on the resources that are affected by this role. For example, the user is no longer EDITOR on Page1.
audit.roleBlockEvents	Role block modified	The portal role block information of a resource has been changed. The event message contains a list of blocked and non-blocked roles on the given resource. As roles can either be inherited or propagated, there are two seperate lists for inheriting roles and propagating roles. If only propagating role blocks have been changed, the list for inheriting roles is empty and vice versa.
audit.ownerEvents	Resource owner modified	The owner of a resource has been changed.
audit.resourceEvents	Resource created	A new resource has been registered. This event is triggered when the resource is registered in Portal Access Control.
	Resource modified	A registered resource has been modified.
	Resource deleted	A registered resource is no longer registered in Portal Access Control. This usually happens when a resource is deleted.
audit.externalizationEvents	Resource externalized	A resource has been externalized. This means that access permissions to this resource are no longer controlled by Portal Access Control, but by an external Access Manager. For example, this can be Tivoli Access Manager.
audit.externalizationEvents	Resource internalized	A resource has been internalized. It is now controlled by Portal Access Control and no longer by an external Access Manager.
audit.userInGroupEvents	User added to group	A user has been added to a group. The user is now a member of this group and therefore inherits access rights from the group.
audit.userInGroupEvents	User removed from group	A user has been removed from a group. The user is no longer a member of that group and does no longer have the inherited access rights.
audit.webModuleEvents	Web Module installed	A new Web module has been installed or deployed.
audit.webModuleEvents	Web Module uninstalled	An installed Web module has been uninstalled.
audit.applicationRoleEvents	Application role created	An application role has been created.
audit.applicationRoleEvents	Application role deleted	An application role has been deleted.
audit.principalToApplicationRoleMappingEvents	Application role assigned	An application role has been assigned to a user. The user has been given the access permissions contained in all the roles that are aggregated in this application role.
audit.principalToApplicationRoleMappingEvents	Application role unassigned	An application role has been unassigned from a user. The user no longer has the access permissions contained in all the roles that are aggregated in this application role.
audit.roleToApplicationRoleMappingEvents	Role added to application role	A portal role has been added to an application role. All permissions contained in the portal role are added to the application role. Effective immediately, these added permissions are given to all users or groups to whom the application role is currently assigned.
audit.roleToApplicationRoleMappingEvents	Role removed from application role	A portal role has been removed from an application role. The users who had this application role no longer have the access permissions that are contained by this role.
audit.domainAdminDataEvents.enable	Domain administration data initialized	The administrative data for a domain, such as administrative user, administrative group, and virtual root resource, has been initialized during the startup of the portal. For the lifetime of the current portal process, this user and group have administrative permissions on the domain resource hierarchy, starting from the virtual root resource. For details about this refer to Access Control Data Management Service. This event is always thrown for each defined domain during server startup. As this is done by the system, no performing user will be logged.