Portal, V6.1

 

Portal configuration services

 

+

Search Tips   |   Advanced Search

 

IBM WebSphere Portal comprises a framework of services to accommodate the different scenarios that portals of today need to address. You can configure some of these services.

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.

Resources | Resource Environment | Resource Environment Providers | [Browse nodes | Browse Clusters] | [node | cluster]

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.

In the following list of parameters the 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.

PortletResponse headers

This section describes the portlet response headers.

 

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.

Notes:

  1. WebSphere Portal V6.1 has the configuration separated into two types:

    • Deployed configuration. This is read-only. The deployed configuration is always read from the file portlet.xml.

    • Administrative configuration. This is read/write.

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

  2. Portlet applications appear in the Enterprise Application list on the console of WAS.

    However, you should never manage them from outside the portal. Instead, manage them by using the 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. 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.

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.

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

 

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:

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.

The following property specifies the database domain tracking daemon

setting:

 

Loader Service

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

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:

 

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

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 e-mail to new members

for composite application communities.

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

    Specify the replacement e-mail address that the mail sending service will use if a sender address does not comply with RFC822. - The mail sending service checks that the sender address of each e-mail complies with RFC822. If the sender address does not comply with RFC822, that sender address is replaced by the e-mail address specified by this property.

    The default is root@your.host.com. This is an example e-mail address; its format is valid by RFC822, but it does not point to real address.

  • mail.jndi.name = (mail/PortalMailService )

    JNDI name of the mail session that is to be used.

    The default is 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 your configuration, you might be able improve your performance by modifying these settings.

    Key Meaning Default
    public.session Set to true to enable public sessions for pages that anonymous users can view without logging in.

    Setting public.session influences the remote cache scope.

    • If true, cache scope is set to non-shared (private).
    • If false, cache scope is set to shared (public).

    Setting public.session to true might reduce performance.

    		false
    public.expires 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.

    		60
    remote.cache.expiration Maximum cache lifetime (in seconds) of a page, both public and private. 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
    remoteCacheInfo.response.header.vary HTTP headers that force a proxy to cache different variants of the same URL. 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

     

    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)

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

    • bucket.<bucket-name>.class

      The type of class that the bucket with the given name is caching.

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

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

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

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

      Controls 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

      The portlet bucket is used to cache the database representation of all portlets stored in the database.

    • application

      The application bucket is used to cache the database representation of all portlet applications stored in the database.

    • theme

      The theme bucket is used to cache the database representation of all themes stored in the database.

    • language

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

    • skin

      The skin bucket is used to cache the database representation of all skins stored in the database.

    • language

      The language bucket is used to cache the database representation of all languages stored in the database.

    • client

      The client bucket is used to cache the database representation of all clients stored in the database.

    • markup

      The markup bucket is used to cache the database representation of all markups stored in the database.

    • servlet

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

    • webmodule

      The webmodule bucket is used to cache the database representation of all Web modules stored in the database.

     

    Portlet Container Service

    This section lists and describes the PortletContainer service related settings.

    The portlet container service also contains the properties for configuring parallel portlet rendering.

     

    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:

     

    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:

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

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

    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)

      Name of an SSL configuration to be used for secure communication as defined in the WAS security configuration.

    • global.sso.domain = domain name

      Specify the domain that starts with a dot, for example .a.com and denotes the range of hosts to which single-sign on cookies, such as LTPA, are forwarded from a client request. If the property is not set, single sign-on cookies are not forwarded to any remote host.

    • global.proxy.http.host = host name

      Specify a proxy host for HTTP URLs. If no proxy host is set, the portal tries to load all HTTP URLs directly.

    • global.proxy.http.port = port number

      Port for the HTTP proxy. If no value is specified, 80 is used as the default value.

    • global.proxy.https.host = host name

      Specify a proxy host for HTTPs URLs. If no proxy host is set, WebSphere Portal tries to load all HTTPs URLs directly.

    • global.proxy.https.port = port number

      Proxy port for HTTPs URLs. If no value is specified, 443 is used as the default value.

    • global.proxy.auth.credentialslot = slot name

      Set this property if you want proxy authentication to 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 then specify the name of this credential slot in this property. The credential must have the type UserPasswordPassive. Proxy authentication applies to the proxy server only, not to the target server of the outbound connection.

    • global.proxy.excludehost = host name

      Specify a particular host for which no proxy connection is used, even if a proxy is configured. You can set this property multiple times. Specify one setting for each host that is excluded from proxy connections.

     

    Cache Manager Service

    The Cache Manager Service is responsible for managing the different caches used in WebSphere Portal V6.1.

    The portal provides two different types of caches...

    1. Shared caches

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

    2. 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 used for all caches unless explicitly overridden by the corresponding cache instance parameter.

      • cacheinstance.cacheidentifier parameters

        They are used to 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 your portal installation.

      Use the Tivoli Performance viewer, that is the WAS PMI client (PMI = Performance Monitoring Interface) to find the optimal settings for your 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 ]

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

      • cacheglobal.size = number

      • cacheinstance.cacheidentifier.size = number

        Define the 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 ]

        Define 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 an infinite lifetime. In this case no timeout is applied and the cache entry is never evicted.

      • randomizePercent = number

      • cacheinstance.cacheidentifier.randomizePercent= number

        Use this parameter to randomize cache entry lifetimes to some extent. If all entries in a cache have the same lifetime, this can result in high loads on the database when reloading entries, as large amounts of entries are evicted at the same time.

        Specify the value for this parameter as a numeric value given in percent. For example, a value of 25 means that all cache entry lifetimes are up to 25 % higher or lower than the default lifetime (given by the lifetime parameter above). No cache entry will have a lifetime lower than 50 % of the default value, no matter how large you specify the value for this parameter. By default no value is specified. In this case lifetimes are not randomized, and all cache entries have the default lifetime.

        If you set the default lifetime parameter above to infinite by the value -1 , the lifetime randomization setting is not applied, even if you specify a value for the radnomizePercent parameter.

        You can view the actual randomized lifetime of a cache entry by enabling tracing for class com.ibm.wps.services.cache.AbstractCache.

      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]

        Controls the eviction algorithm behavior.

      • cacheglobal.admint-threshold = number

      • cacheinstance.cacheidentifier.admint-threshold = number

        Admittance threshold. Use this parameter to 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 )

      This parameter specifies a list of one or more preprocessors that are used. It can take multiple values.

      Notes:

      1. To add your own custom preprocessors in the administrative console, first enter the default values in the same sequence as given below and then append your custom preprocessors to the end of the list. This is for the following reasons:

        1. If you specify a value for this parameter, that value overwrites the default value.

        2. The default value is mandatory. Therefore you cannot replace it by a different value.

        3. The preprocessors must be arranged in the order given below, as for requests they are processed in that order.

      2. The required syntax is (classname (, classname) * ) 1 .

      The default value... 

      preprocessors = com.ibm.wps.state.preprocessors.selection.StandardPortalSelectionImpl preprocessors = com.ibm.wps.state.preprocessors.urlmapping.URLMappingPreProcessor,
                com.ibm.wps.resolver.friendly.preprocessors.FriendlyPreProcessor,
                com.ibm.wps.resolver.portal.ResolvedPreprocessor,
                com.ibm.wps.state.preprocessors.selection.StandardPortalSelectionImpl,
                com.ibm.wps.state.preprocessors.selection.FragmentSelectionImpl,
                com.ibm.wps.state.preprocessors.selection.ResourceSelectionImpl,
                com.ibm.wps.state.preprocessors.eclipse.ExtensionPreProcessor,
                com.ibm.wps.state.preprocessors.portlet.RequestParameterMerger
      Of the values given above the following two selection preprocessors are alternative options. They process the page selected by the user. All other preprocessors are for portal internal use only and must not be changed.

      Both of the following selection preprocessors are mutually 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.) This value is the default.

      • 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. You can replace this value for the default value above.

    • keymanager.lru.size = (integer )

      Specify the 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 specified 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.

      You 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

        Specify the 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 your portal. URL normalization is required to enable external search engines to crawl the content of your 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 )

      Specify the XSL stylesheet file that defines the transformation that should be used in order to normalize the portal URL. (This parameter needs to be set all on one line and concatenated.) 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 style sheets...

    • 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

      Defines the 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

      Defines the language in which the page is presented.

    • screen-template

      Defines the screen that is used on the portal page.

    • theme-template

      Defines the theme that is used on the portal page.

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

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

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

    Contains the configuration settings for Portal Access Control. The domain short names have to correspond to the domain names that are 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:

    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)

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

      Determine 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 you 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)

      This property is only applicable 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:

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

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

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

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

      1. The resource will be externalized.

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

     

    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

        Disables 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

        Enables the execution of the portal JAAS login. You 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.

    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.

    • login.explicit.filterchain = <none>

      Specify the custom filters for the filter chain that is triggered for an explicit login by user name and password. The classes listed in this property must implement the interface...

      com.ibm.portal.auth.ExplicitLoginFilter

    • login.implicit.filterchain = <none>

      Specify the custom filters for the filter chain that is triggered for an implicit login, that is if the user is already authenticated to WAS but has no portal session yet. The classes listed in this property must implement the interface com.ibm.portal.auth.ImplicitLoginFilter.

    • logout.explicit.filterchain = <none>

      Specify the custom filters for the filter chain that is triggered for an explicit logout. The classes listed in this property must implement the interface com.ibm.portal.auth.ExplicitLogoutFilter.

    • logout.implicit.filterchain = <none>

      Specify the custom filters for the filter chain that is triggered for an implicit logout, that is if the user got a session timeout. The classes listed in this property must implement the interface com.ibm.portal.auth.ImplicitLogoutFilter.

    • sessiontimeout.filterchain = <none>

      Specify the custom filters for the filter chain that is triggered directly after an idle timeout of the session occurred. The classes listed in this property must implement the interface com.ibm.portal.auth.SessionTimeoutFilter.

    • sessionvalidation.filterchain = <none>

      Specify the custom filters for the filter chain that is triggered for every request before the action handling and rendering is processed. The classes listed in this property must implement the interface com.ibm.portal.auth.SessionValidationFilter.

    • filterchain.properties.. = <none>

      Use an arbitrary set of properties according to the above pattern to specify properties for any of your custom filters. The property value is then available to the specified filter class in the SecurityFilterConfig object passed to its init method.

     

    Credential Vault Service

    Specify vault adapters used by the Credential Vault Service to store credential secrets in the portal server datastore.

    Two default vault adapters are available...

    • default-release
    • default-customization

    For each implementation, define a...

    • unique string type
    • class name
    • domain
    • configuration file (optional)
    • managing resources (optional)
    • read only flag (optional)

    The following vault adapter properties are in the format...

    vault.type.key

    Replace type by the vault adapter implementation type

    Replace key with one of the following...

    class Vault adapter Implementation class name, but without the .class extension. Mandatory
    config Path of a configuration file that your 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. 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. This parameter is optional.

    If set to true, the manageresources parameter is ignored. If you omit this parameter, it will default to true .

    Additionally, set the following configuration values:

    systemcred.dn Distinguished name of the vault administrative user. All system credentials are stored under the user's account. This key is set to the portal administrative user by default.
    export.userDN This is the user DN value of the XML Access user that is allowed to import/export secrets via the XML Configuration interface. This is usually the same user DN string as defined in the same configuration file under the key systemcred.dn. This user needs authority to use the XML Configuration interface and has to be used during the import/export. Otherwise an import/export of credential secrets is not possible.
    export.cipher The cipher used during export for encryption. This cipher has to be available via Java JCE in the WebSphere Portal system.

    The default value is AES.

    export.keyLength Number of bits used as key length for the cipher. The default value is 128.
    export.enforceSSL Controls if credential import/export must be done via secured HTTP connection (value=true) or if it shall be allowed to import/export credentials also via an unsecured HTTP connection (value=false). The default value is true.

     

    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.

    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)

      This flag indicates whether the configuration in this file has been configured to 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:

    To configure the connection between WebSphere Portal and 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 your Protected Object Space for Portal Server entries.

    • externalaccesscontrol.pduser = sec_master

    • externalaccesscontrol.pdpw = passw0rd

      Use these parameters to 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: 

      AppServer_root/bin/PropFilePasswordEncoder 
portal_server_rootproperties/ExternalAccessControlService.properties 
        externalaccesscontrol.pdpw

      This command should be typed on one line in a command line window.

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

      Specify the 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)

      This parameter is optional. Whether Access Control Lists (ACLs) are created in Access Manager for roles that are stored externally.

      The default is true.

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

    To configure the connection between WebSphere Portal and your Policy Server...

    • externalaccesscontrol.domainname = WebSphere Portal V 6

      Specify the 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)

      Specify the 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:

      AppServer_root/bin/PropFilePasswordEncoder portal_server_root/properties/ExternalAccessControlService.properties

      externalaccesscontrol.agentsecret

      Type this command on one line in a command line window.

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

      AppServer_root/bin/PropFilePasswordEncoder portal_server_root/properties/ExternalAccessControlService.properties externalaccesscontrol.password

      Type this command on one line in a command line window.

    • externalaccesscontrol.userdir = (User Directory 1)

      Specify the User Directory that is associated with the domain. You 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. You can specify this property as either externalaccesscontrol.failOver or as externalaccesscontrol.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, . . .

      Specify the 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 (see above) to true . You 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)

        The accounting port for the Policy Server.

        The default is 44441.

      • authenticationPort = (44442)

        The authentication port for the Policy Server.

        The default is 44442.

      • authorizationPort = (44443)

        The authorization port for the Policy Server.

        The default is 44442.

      • connectionMax = (10)

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

        The connection timeout in seconds.

        The default is 20.

      An example for server 10.0.0.1... 

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

      This is the 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

      This property defines the 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 you 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, you can disable the inclusion of the IDs.

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

     

    Puma Store and Validation services

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

     

    Puma Store service

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

    • store.puma_default.user.fbadefault.filter =

      Defines the default search attribute for users. Usually this is the same as the Relative Distinguished Name (RDN) attribute of the LDAP. Depending on your environment, it might be a different attribute.

      The default is set to the same value as that of the LDAPUserPrefix in the file wkplc.properties.

    • store.puma_default.group.fbadefault.filter =

      Defines the default search attribute for groups. Usually this is the same as the RDN attribute of the LDAP. Depending on your environment, it might be a different attribute.

      The default is set to the same value as that of the LDAPGroupPrefix in the file wkplc.properties.

    • store.puma_default.user.base.attributes =

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

    • store.puma_default.user.minimum.attributes =

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

    • store.puma_default.group.minimum.attributes =

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

    • store.puma_default.userManagement.cacheMode = (true)

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

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

      Portal User Management can generate the common name (CN) of a user automatically. This property defines how the CN is generated. You 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}.

    • store.puma_default.puma.commonname.parts =

      Defines the number of dynamic parts in the common name.

    • store.puma_default.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)

      Defines the maximum number of characters that is allowed for the defined YOURATTRIBUTE.

      The default is 60.

    • user.YOURATTRIBUTE.min = (1)

      Defines the minimum number of characters that is allowed for the defined YOURATTRIBUTE.

      The default is 1.

    • user.YOURATTRIBUTE.charset = (ascii)

      Defines the 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:

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

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

    Properties for group validation:

    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 documentation about the portal XML configuration interface..

     

    Parent topic

    Set service configuration properties

     

    Related tasks

    Enabling People Finder for anonymous users
    Set service configuration properties

     

    Related reference

    Overview of configuration services