Portal configuration services


Overview

You can no longer set these properties by simply changing the property value in the properties file and restarting the portal. The configuration for each service is stored in and accessible through the IBM WAS administrative console. For more information about how to set properties refer to the topic about Setting service configuration properties.


Services

Services that are not described in the following are purely for portal internal usage. Do not modify them in any way.

Values given in parentheses are the default values. Parameters marked with <none> have no default values.


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. They are listed and described in the WSRP context under Use WSRP services wcm7 in the respective topics for which they are relevant.

was.home = (${WAS_INSTALL_ROOT})

wps.home = (${WPS_INSTALL_ROOT})

command.sessionvalidator = (SessionValidatorAuth)

command.login = (LoginUserAuth)

command.logout = (LogoutUserAuth)

redirect.login = (true)

redirect.login.ssl = (false)

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

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

redirect.logout = (false)

redirect.logout.ssl = (false)

redirect.logout.url = <none>

ldapserviceattributename.attribute [optional] = (uid)

multiple.realms.enabled = false

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

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

host.name = <none>

host.port.http = <none>

host.port.https = <none>

security.css.protection = (true)

redirect.commands = (false)

uri.context.path = (/wps)

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

uri.home.public = (/portal)

uri.home.protected = (/myportal)

uri.home.doc = (/doc)

uri.home.substitution = (false)

wsrp.resourceproxy.basic.auth.credentialslot = <none>

wsrp.resourceproxy.no.header.forwarding = <none>

persistent.session.level = (0)

persistent.session.option = (0)

timeout.resume.session = (false)

session.security.use.errorcode = (true)

session.security.errorcode = (409)

session.security.redirecturl = <none>

portal.session.protection = (true)

portal.enable.filtering = (true)

portlet.url.find = <none>

portlets.unauthorized.visible = (false)

portletcontainer.std.custom.windowStates = <none>

allow.derived.titles = (true)

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

wps.mappingurl.enabled = (true)

navigation.portletmenu.mode = (1)

navigation.expansion.defaultstate = (false)

page.reload.interval = (0)

wsrp.caching.enabled = (true)

friendly.enabled = (true)

friendly.redirect.enabled = (false)

friendly.pathinfo.enabled = (true)

portlet.iwidget.markup.prefetching = (true)

wcm.pages.enabled = (true)

wcm.config.seedlist.version = (1.0)

wcm.config.seedlist.servletpath = (/seedlist)

PortletResponse headers:

This section describes the portlet response headers.

portletcontainer.response.headers.additionallyNotAllowed = <none>

portletcontainer.response.headers.forceAllowed = (none)

portlet.enable.transcoding = (true)

portlet.automaximize = (false)

proxy.enable.app.config = (false)

content.topology.writelock.timeout = milliseconds (default=25000)

content.topology.writelock.dump = true|false (default=false)

com.ibm.wps.filestore.JCRWebdavTreeModelFactory.cacheClearOnRestart = true|false (default=true)

proxy.cv.slot.regex = your regular expression with allowed slot IDs


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, and stopping portlet applications.

WebSphere Portal v7.0 has the configuration separated into two types:

The deployed configuration can be modified by administrative changes, for example, by using administrative portlets or xmlaccess.sh. The administrative configuration is never overwritten by changes to the deployed configuration.

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 portal administration portlets or xmlaccess.sh 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. You can identify the name of such a portlet application by a portal specific identifier prefix PA_<name> . This identifier is appended to the name. An example for such a name is PA_WPS_Welcome . The name in turn is derived from the name of the WAR file when the portlet application is installed. You can change this administrative name with an update of the portlet application.

In the following list of parameters the values given in parentheses are the default values.

was.admin.host = (localhost)

use.admin.user = (true)

was.notification.timeout = (300)

portletapp.starting.weight = (100)

portletapp.shared.library.list

portletapp.reload.enabled = preserve

discard.config.interval = (60)

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.

delete.temp.files = (true)

shorten.deployment.names = (true)

deployment.names.limit = (21)

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

deployment.debug.log.times = (false)


Data Store Service

WebSphere Portal uses a database to store configuration data for pages, clients, markup, and all other resources.

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)

datasource.machineid

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

DBMS used DBMS value for xxx.datasource.dbms properties
Apache Derby DERBY
IBM DB2 Universal Database™ for z/OS DB2_ZOS
IBM DB2 Universal Database Enterprise Server Edition DB2
IBM DB2 Universal Database for i DB2_ISERIES
Oracle Enterprise Edition ORACLE
Microsoft™ SQL Server Enterprise Edition SQLSERVER2005

rel.datasource.schema = ( RELEASE )

cust.datasource.dbms = your_DBMS

cust.datasource.schema = ( CUSTOMIZATION )

comm.datasource.dbms = your_DBMS

comm.datasource.schema = ( COMMUNITY )

jcr.datasource.dbms = your_DBMS

jcr.datasource.schema = ( JCR )

The following property specifies the database domain tracking daemon setting:

domain.tracker.wait = (1000)

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, and supporting classes for screen templates, skin templates, and 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


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.

Give the system default locale is necessary because Locale.getDefault() is set to the 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

locale.default.country

locale.default.variant

The default language must be supported by WebSphere Portal. If you 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.


Mail Service

The Mail Service allows you to configure the properties that are used by the feature Enable sending email to new members for composite application communities.

mail.from.fallback = ( root@your.host.com )

mail.jndi.name = ( mail/PortalMailService )


Navigator Service

The Navigator Service allows you to specify a number of settings. Among these are settings for cache scope and cache expiration. Depending on configuration, you might be able improve performance by modifying these settings. For detailed information about page caching for improved performance, refer to the section about tuning the portal.

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

Set public.session to true might reduce performance.

Set public.session to true might reduce performance.

false
public.expires Specifies the cache expiration time (in seconds) for caches outside of WebSphere 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.

WebSphere 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 WebSphere 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 WebSphere Portal sets the following header fields:

  • The Expires header with the expiration time added to the system date and time.

  • 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, WebSphere Portal defaults the value to 60 seconds.

The response of WebSphere Portal sets the following header fields:

  • The Expires header with the expiration time added to the system date and time.

  • 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, WebSphere Portal defaults the value to 60 seconds.

Therefore this value might not be static for all responses resulting from requests to unauthenticated pages.

The response of WebSphere Portal sets the following header fields:

  • The Expires header with the expiration time added to the system date and time.

  • 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, WebSphere Portal defaults the value to 60 seconds.

The response of WebSphere Portal sets the following header fields:

  • The Expires header with the expiration time added to the system date and time.

  • 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, WebSphere Portal defaults the value to 60 seconds.

60 (sec)
remote.cache.expiration Maximum cache lifetime (in seconds) of a page, both public and private. Use 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, WebSphere Portal defaults the value to zero (0 seconds).

0 (sec)
remoteCacheInfo.response.header.vary 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 WebSphere 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
public.cache-control Value which is set for the cache-control HTTP header field when the portal generates a response in request for public pages. This header field controls the behavior of all caching mechanisms along the request/response chain. no-cache
private.cache-control Value which is set for the cache-control HTTP header field when the portal generates a response in request for private pages. This header field controls the behavior of all caching mechanisms along the request/response chain. no-cache


Registry Service

The RegistryService loads and caches a small number of objects which are regularly accessed in the engine. This improves performance, however the trade off 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, try reducing the refresh rate for the respective entities.

default.interval = (1800)

bucket.<bucket-name>.class

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

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

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

The bucket names are described in the following:

theme

language

skin

language

client

markup


Portlet Container Service

This section lists and describes the PortletContainer service related settings.

legacy.portlet.enable.filtering = (true)

The portlet container service also contains the properties for configuring parallel portlet rendering. For details refer to the separate topic about parallel portlet rendering Parallel portlet rendering wcm7.


Pipe Pool Service

Pipes are used to buffer content. For example, for parallel portlet rendering the pipes are used to pass portlet content between threads.

To improve performance, all pipes are held in a pool for reuse. Configuration settings for the pool are located in the PipePoolService.

Variations in the usage of the pipes result in increase or decrease of the pool size. You 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.

The pipes are also known as queues. You can configure pipes that are managed by this pool by setting the following parameter:

For details refer to the separate topic about parallel portlet rendering Parallel portlet rendering wcm7.


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. You can configure these settings at either of the following locations:

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

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

Proxy protocol and port settings:

This section allows you 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

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

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

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

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

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

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

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

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

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

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, you can socksify the TCP/IP stack of system.

Examples:

The name of the HTTP proxy host: 

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

The name of the HTTP proxy port: 

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

The name of the tunneling HTTPs proxy host: 

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

The name of the HTTPs proxy port: 

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


HTTP client service

Several components of the portal need to open HTTP or HTTPs connections to other resources. The HTTP Client Service provides a central point for configuration properties to these outbound connections. You can set global settings for the SSL configuration and proxy server usage.

These settings do not currently replace all individual portlet proxy configuration settings. To set the proxy settings for specific portlets, consult the documentation for each portlet for how to modify their specific settings.

Some functional components of the portal can overwrite each of the settings if the component configuration differs from the global value. The following describes the global settings only; if a component allows you to set component specific properties, these are described in the respective component documentation.

global.ssl.configuration = (NodeDefaultSSLConfig)

global.sso.domain = domain name

global.proxy.http.host = host name

global.proxy.http.port = port number

global.proxy.https.host = host name

global.proxy.https.port = port number

global.proxy.auth.credentialslot = slot name

global.proxy.excludehost = host name


Cache Manager Service

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

Shared caches

Non-shared caches

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

cacheglobal parameters

cacheinstance.cacheidentifier parameters

Change some or all of these settings can dramatically improve or impair portal performance. Therefore it is recommended 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 (PMI = Performance Monitoring Interface) to find the optimal settings for 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 ]

cacheglobal.size = number

cacheinstance.cacheidentifier.size = number

cacheglobal.shared = [ true | false ]

cacheinstance.cacheidentifier.shared = [ true | false ]

cacheglobal.lifetime = number

cacheinstance.cacheidentifier.lifetime = number

randomizePercent = number

cacheinstance.cacheidentifier.randomizePercent= number

You 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]

cacheglobal.admin-threshold = number

cacheinstance.cacheidentifier.admin-threshold = number

The cache identifiers are described in the following:

com.ibm.wps.pe.deployedresources

com.ibm.wps.pe.portletregistry

com.ibm.wps.pe.portletdefinition


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 )

keymanager.lru.size = ( integer )


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:

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

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

portlet-mode

window-state

renderparameters

selection

solo

locale

screen-template

theme-template

You can also set up 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 own XSL stylesheet and set it as the value for the URL normalization parameter:

  1. Here is an example for creating 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>
 
    <!-- Traverse through the tree starting at the root element -->
    <xsl:template match="root">
         <xsl:copy>
              <xsl:copy-of select="@*"/>
    <!-- Search for the state node with the attribute type = navigational -->
              <xsl:apply-templates select="state [@type='navigational']"/>
         </xsl:copy>
    </xsl:template>
 
    <!-- Selection of all states which should stay coded in the URL -->
    <!-- Allowed States: portlet-mode, window-state, renderparameters (param, value, text), 
       selection, solo, locale , screen-template -->
    <xsl:template match="state">
         <xsl:copy>
              <xsl:copy-of select="@*"/>
              <xsl:apply-templates select=" . . . "/>
. . .
         </xsl:copy>
    </xsl:template>
 
. . . 
. . . 
. . . 
 
</xsl:stylesheet>

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

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, update that name in the properties.

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 defined for the Data Store 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 distinguished name of the administrative user for this domain

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

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

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=Your Company
accessControlDataManagement.domain.rel.admingroup=cn=Admins,o=Your Company
accessControlDataManagement.domain.rel.virtualresource=PORTAL
accessControlDataManagement.domain.cust.adminuser=uid=Bob,o=Your Company
accessControlDataManagement.domain.cust.admingroup=cn=Admins,o=Your Company
accessControlDataManagement.domain.cust.virtualresource=PORTAL
accessControlDataManagement.domain.comm.adminuser=uid=Bob,o=Your Company
accessControlDataManagement.domain.comm.admingroup=cn=Admins,o=Your Company
accessControlDataManagement.domain.comm.virtualresource=PORTAL
accessControlDataManagement.domain.jcr.adminuser=uid=Bob,o=Your Company
accessControlDataManagement.domain.jcr.admingroup=cn=Admins,o=Your Company
accessControlDataManagement.domain.jcr.virtualresource=PORTAL

The following additional properties of the Access Control Data Management Service are optional:

accessControlDataManagement.enableNestedGroups = (true)

accessControlDataManagement.enableTargetResourceGroupInheritance = (false)

accessControlDataManagement.reorderRoleNames = (false)

accessControlDataManagement.externalizeAllRoles = (false)

accessControlDataManagement.createAdminMappingXMLAccess = (true)

Connect 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 )

accessControlDataManagement.ldapFailoverInterval = ( 60 )


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)

Use the following properties to define the custom filters in the various authentication filter chains in the portal. Each of these properties takes a comma-separated list of the fully qualified class names of the custom filter implementations. For concept information about authentication filters refer to Configure authentication filters wcm7.

login.explicit.filterchain = <none>

login.implicit.filterchain = <none>

logout.explicit.filterchain = <none>

logout.implicit.filterchain = <none>

sessiontimeout.filterchain = <none>

sessionvalidation.filterchain = <none>

filterchain.properties.. = <none>


Credential Vault Service

You can 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 data store. For each implementation, define a unique string type, a class name, and a domain. Optionally, you can specify a configuration file, managing resources, and a read only flag.

You 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 you can append:

class

config

domain = (rel)

manageresources = (false)

readonly = (true)

Additionally, you can set the following configuration values:

systemcred.dn

export.userDN

export.cipher

export.keyLength

export.enforceSSL


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. These are the parameters set by the configuration of external security managers procedures.

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)

externalaccesscontrol.server = WebSphere_Portal

externalaccesscontrol.application = WPS

externalaccesscontrol.cell = cell

Access Manager configuration:

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

externalaccesscontrol.pdroot = (/WPSv6)

externalaccesscontrol.pduser = sec_master

externalaccesscontrol.pdpw = passw0rd

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

externalaccesscontrol.createAcl = (true)

externalaccesscontrol.pdactiongroup = ([WPS])

externalaccesscontrol.pdAction = (m)

Computer Associates eTrust SiteMinder Policy Server information:

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

externalaccesscontrol.domainname = WebSphere Portal V 7

externalaccesscontrol.scheme = (Basic)

externalaccesscontrol.agentname = wpsagent

externalaccesscontrol.agentsecret = passw0rd

externalaccesscontrol.admin = siteminder

externalaccesscontrol.password = passw0rd

externalaccesscontrol.userdir = (User Directory 1)

externalaccesscontrol.failOver = (false)

externalaccesscontrol.servers = server1,server2, . . .


Auditing Service

The auditing service allows you 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 section Available events lists and describes the events that are available for auditing.

The audit logging output is written to the audit log file. No other log messages are written to this file. For an explanation of the contents of the audit log file refer to the section Audit log 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)

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

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

audit.logFileName = log/audit_$create_time.log

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


audit.showTransactionID.enable = (true)

Set the events that you want to enable to the value true.... 

     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
     audit.domainAdminDataEvents.enable
     audit.designerDeployServiceEvents.enable
     audit.impersonationEvents.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...

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

Events for actions that run in a transaction are written to the log file when the transaction is 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 auditing service events

If you enable one group, all events in that group are logged.

Audit logging group Audit logging event Meaning of the event
audit.groupEvents Group created event A new user group has been created via portal UIs.
  Group modified event A user group has been modified via portal UIs.
  Group deleted event A user group has been deleted via portal UIs.
audit.userEvents User created event A new user has been created via portal UIs.
  User modified event A user has been modified via portal UIs.
  User deleted event A user has been deleted via portal UIs.
audit.portletEvents Portlet Application created event A new web module or portlet application has been created via portal UIs.
  Portlet Application modified event A web module or portlet application has been modified via portal UIs.
  Portlet Application deleted event A web module or portlet application has been deleted via portal UIs.
audit.roleEvents Role assigned event 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 event 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 event 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 separate 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 event The owner of a resource has been changed.
audit.resourceEvents Resource created event A new resource has been registered. This event is triggered when the resource is registered in Portal Access Control.
  Resource modified event A registered resource has been modified.
  Resource deleted event A registered resource is no longer registered in Portal Access Control. This usually happens when a resource is deleted.
audit.externalizationEvents Resource externalized event 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 event 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 event 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 event 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 event A new web module has been installed or deployed.
  Web Module uninstalled event An installed web module has been uninstalled.
audit.applicationRoleEvents Application role created event An application role has been created.
  Application role deleted event An application role has been deleted.
audit.principalToApplicationRoleMappingEvents Application role assigned event 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 event 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 event 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 event 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 event 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 the 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.
audit.designerDeployServiceEvents.enable Component installed event A portlet application has been created by using IBM Lotus Component Designer.
  Component modified event A portlet application created by using IBM Lotus Component Designer has been modified.
  Component uninstalled event A portlet application created by using IBM Lotus Component Designer has been deleted.
audit.impersonationEvents Impersonation started event A user started impersonation with another user.
  Impersonation ended event A user ended impersonation with another user.
  Impersonation attempted with no permission event A user tried to impersonate another user but has no permission.


Puma Store and Validation services

The following sections list and describe the configuration services for Portal User Management (PUMA): the Puma Store Service and the Puma Validation Service.


Puma Store Service

The Puma Store Service contains the configuration settings for Portal User Management.

The following properties configure both the Portal User Management and the PUMA SPI:

store.puma_default.user.fbadefault.filter =

store.puma_default.group.fbadefault.filter =

store.puma_default.user.base.attributes =

store.puma_default.user.minimum.attributes =

store.puma_default.group.minimum.attributes =

store.puma_default.userManagement.cacheMode = (true)

store.puma_default.logDuplicateKeyExceptions = (true)

The following properties configure only the Portal User Management, but not the PUMA SPI:

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

store.puma_default.puma.commonname.parts =

store.puma_default.puma.commonname.X =


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)

user.YOURATTRIBUTE.min = (1)

user.YOURATTRIBUTE.charset = (ascii)

user.YOURATTRIBUTE.extra_chars = ( -._ )

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 the Puma Store Service:

user.UNIQUEID Value of user.fbadefault.filter attribute
defined in Puma Store Service
user.UNIQUEID.min 1
user.UNIQUEID.max 60
user.UNIQUEID.charset ascii
user.UNIQUEID.extra_chars -._

Properties for group validation:

group.RDN Value of group.fbadefault.filter attribute defined
in Puma Store Service
group.extra -,_
group.RDN.min 1
group.RDN.max 200

Properties for password validation:

password.min_characters 5
60
ascii
-._


+

Search Tips   |   Advanced Search