+

Search Tips   |   Advanced Search

Portal configuration services

  1. Configuration Service
  2. Deployment Service
  3. Data Store Service
  4. Loader Service
  5. Localizer Service
  6. Navigator Service
  7. Registry Service
  8. Portlet Container Service
  9. Pipe Pool Service
  10. Content Access Service
  11. HTTP client service
  12. Cache Manager Service
  13. State Manager Service
  14. Administrator Unique Names Mapping Service
  15. Portal Security Services
  16. Access Control Data Management Service
  17. Authentication Service
  18. Credential Vault Service
  19. External Access Control Service
  20. Auditing Service
  21. Puma Store and Validation services
  22. Puma Store Service
  23. Puma Validation Service
  24. xmlaccess.sh


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.

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.

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

    • Deployed configuration. Read-only. The deployed configuration is always read from the file portlet.xml.
    • Administrative configuration. Read/Write.

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

  2. Portlet applications appear in the Enterprise Application list on the WAS admin console. However, you should never manage them from outside the portal. Instead, manage them 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 admin console. We can identify the name of such a portlet application by a portal specific identifier prefix...

      PA_name

    For example...

      PA_WPS_Welcome

    The name in turn is derived from the name of the WAR file when the portlet application is installed. We 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 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 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: 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 on 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.

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:

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.


Navigator Service

Key Meaning Default value
public.session Set true to give anonymous users a public session. When true, the remote cache scope for public pages is non-shared (private). If false, remote cache scope is set to shared (public). There are performance implications with the true setting. 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. 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 informatione 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 (sec)
remote.cache.expiration Maximum cache lifetime (in seconds) of a page, both public and private. Use this setting to specify a global value for the expiration of pages in remote caches. Setting this value to 0 switches caching off in remote caches. If the legacy setting is not available, this setting is used for authenticated and unauthenticated pages. If the legacy setting is available, then the smaller of the two values is used for unauthenticated pages only. In this case the remote.cache.expiration setting is used for authenticated pages in general. If theme, composition, and portlets contribute remote cache information, then the global settings also contribute to the information. In this case the lowest of the values of all contributors is used, including the global settings.

The default setting specified in this file is 60 seconds. If no value is specified, 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 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 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.

The bucket names are described in the following:

theme Cache the database representation of all themes stored in the database.
skin Cache the database representation of all skins stored in the database.
language Cache the database representation of all languages stored in the database.
client Cache the database representation of all clients stored in the database.
markup Cache the database representation of all markups 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. For details refer to the separate topic about parallel portlet rendering 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. 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 ratethat is how often the pool size is actually reduced as determined by the hysteresis function.

    parallelRenderingPoolHysteresis = (10)

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

    parallelRenderingPoolCompactRate = (300)

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

The pipes are also known as queues. Configure pipemanaged by this pool by setting the following parameter:

    parallelRenderingPoolQueueSize = (5120)

    Size of the queues in bytes. The default is 5120.

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


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

Proxy protocol and port settings:

This section allows us to specify proxy protocol and port settings for different protocols. You must specify for each protocol the name and port number of the proxy servers that we use.

The general format is as follows:

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

Examples:

The name of the HTTP proxy host:

The name of the HTTP proxy port:

The name of the tunneling HTTPs proxy host:

The name of the HTTPs proxy port:


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. We can set global settings for the SSL configuration and proxy server usage.

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

  2. 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 us to set component specific properties, these are described in the respective component documentation.


Cache Manager Service

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

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

Change some or all of these settings can dramatically improve or impair portal performance. Therefore IBM recommends not to change the shared setting for any cache unless the consequences are absolutely understood and agreed. To determine the optimal values for the size, lifetime, admit-threshold and replacement parameters, monitor the cache parameters during the staging phase of the portal installation. Use the Tivoli Performance viewer that is the WAS PMI client (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:

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

The cache identifiers are described in the following:


State Manager Service

Manage the navigational state of the portal.


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:

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

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

  1. Here is an example for creating our 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 updata that name in the properties. This is required so that the theme and administration portlets still function. The available mappings are defined as follows: 

     # ----------------------------------------------- #
     # Portal administration page unique names mapping #
     # ----------------------------------------------- #
     # Internal key           unique name              #
     # ----------------------------------------------- #
     #
     #CONTENT_LAYOUT          = ibm.portal.Content
     #APPEARANCES             = ibm.portal.Appearance
     #MANAGE_PAGES            = ibm.portal.Manage Pages      #UNIQUE_NAMES            = ibm.portal.Custom Unique Names
     #ASSIGN_ROLES            = ibm.portal.Resource Permissions      #PROPERTIES_PORTLET      = ibm.portal.Page Properties       
     #MY_FAVORITES            = wps.My Favorites       
     #ORGANIZE_FAVORITES      = wps.Organize Favorites       
     #SET_PERMISSIONS         = ibm.portal.Locks         
     #MANAGE_LOG              = ibm.portal.Enable Tracing         
     #MY_PORTAL               = ibm.portal.Home
     #ADMINISTRATION          = ibm.portal.Administration
     #PAGE_CUSTOMIZER         = ibm.portal.Page Customizer       
     #PORTLET_MANAGER         = ibm.portal.Web Modules       
     #MANAGE_MY_PORTLETS      = ibm.portal.Portlets
     #MANAGE_MY_PORTLET_APPS  = ibm.portal.Applications
     #MANAGE_WEBSERVICES      = ibm.portal.Web Services      
     #IMPORTXML               = ibm.portal.Import XML      
     #SEARCH_CENTER           = ibm.portal.Search Center
     #VIRTUAL_PORTAL          = ibm.portal.Virtual Portal       
     #LOGIN                   = wps.Login       
     #SELFCARE                = wps.Selfcare      
     #APP_PROPERTIES          = ibm.portal.Template and Application Properties
     #APP_PARAMETER           = ibm.portal.Template Parameters
     #APP_ROLES               = ibm.portal.Application Roles
     #APP_TEMPLATES           = ibm.portal.Templates
     #APP_MEMBERSHIP          = ibm.portal.Application Membership
     #APP_CATALOG             = ibm.portal.Catalog
     #APP_LAYOUT              = ibm.portal.Template and Application Layout
     #PZN_PICKER_PAGE         = ibm.portal.Personalization.Picker

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


Portal Security Services

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


Access Control Data Management Service

The Access Control Data Management Service contains the configuration settings for Portal Access Control. The domain short names have to correspond to the domain namedefined for the Data Store Service.

The following set of properties is mandatary for each database domain containing 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:

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.


Authentication Service

The Authentication Service contains the configuration settings for portal authentication, which is generally performed with a user ID and password.

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.

login.implicit.filterchain = <none>

Custom filters for the filter chain that is triggered for an implicit loginthat 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...

logout.explicit.filterchain = <none>

Custom filters for the filter chain that is triggered for an explicit logout. The classes listed in this property must implement the interface...

logout.implicit.filterchain = <none>

Custom filters for the filter chain that is triggered for an implicit logouto that is if the user got a session timeout. The classes listed in this property must implement the interface...

sessiontimeout.filterchain = <none>

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>

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 previous pattern to specify properties for any of the 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

We can use the Vault Service configuration to specify Vault Adapter implementations 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, we can specify a configuration file, managing resources, and a read only flag.

We can define the following properties for each Vault Adapter Implementation Type. To differentiate the settings for each type, the properties are in the format vault.type.key . Replace type by the Vault Adapter Implementation Type, and replace key by the key. The following list shows the keys that we can append:

Additionally, we can set the following configuration values:


External Access Control Service

The External Access Control Service is responsible for collecting any authorization data from external security managers, such as 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.

Access Manager configuration:

Configure the connection between WebSphere Portal and the Tivoli Access Manager.


Auditing Service

The auditing service allows us to log has 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 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.

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

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

You determine the events to be logged by enabling the appropriate properties as required. Set the events 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
  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 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, set...

Audit log file:

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 guarantees that the related action was completed successfully.

Available events:

This section lists the events that we can log using the auditing service. They are listed by the groups in which they are available. If you enable one group, all events is 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.
audit.groupEvents Group modified event A user group has been modified via portal UIs.
audit.groupEvents Group deleted event A user group has been deleted via portal UIs.
audit.groupEvents User created event A new user has been created via portal UIs.
audit.groupEvents User modified event A user has been modified via portal UIs.
audit.groupEvents 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.
audit.portletEvents Portlet Application modified event A web module or portlet application has been modified via portal UIs.
audit.portletEvents 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.

audit.roleEvents 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.resourceEvent Resource created event A new resource has been registered. This event is triggered when the resource is registered in Portal Access Control.
audit.resourceEvents Resource modified event A registered resource has been modified.
audit.resourceEvents 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.

audit.externalizationEvents 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.
audit.userInGroupEvents User removed from group event A user has been removed from a group. The user is no longer a member on 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.
audit.webModuleEvents Web Module uninstalled event An installed web module has been uninstalled.
audit.applicationRoleEvents Application role created event An application role has been created.
audit.applicationRoleEvents Application role deleted event An application role has been deleted.
audit.principalToApplicationRoleMappingEvent 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.
audit.principalToApplicationRoleMappingEvents 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.
audit.roleToApplicationRoleMappingEvents 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 permissione 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 using IBM Lotus Component Designer.
 audit.designerDeployServiceEvents.enable Component modified event A portlet application created using IBM Lotus Component Designer has been modified.
 audit.designerDeployServiceEvents.enable Component uninstalled event A portlet application created using IBM Lotus Component Designer has been deleted.
audit.impersonationEvents Impersonation started event A user started impersonation with another user.
audit.impersonationEvents Impersonation ended event A user ended impersonation with another user.
audit.impersonationEvents 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:

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


Puma Validation Service

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

Properties for user validation:

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

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

Properties for group validation:

Properties for password validation:


xmlaccess.sh


Parent: Set service configuration properties
Related:
Language support
Related: Overview of configuration services
Web Content Manager configuration services
User IDs and passwords