19 Managing WebCenter Personalization

19.2.1 WebCenter Personalization Installation Requirements

If you are using the CMIS or Activity Graph data providers, or the People Connection locator within a Personalization Conductor scenario, then WebCenter Spaces must be installed. For High Availability environments only, Coherence is also required.

19.2.2 WebCenter Personalization Configuration Requirements

If you are using the CMIS provider, Activity Graph provider, PeopleConnections locator, or custom providers you must configure them as shown in Section 19.4, "Configuring Providers."

If you are using Content Presenter to present content in WebCenter Spaces or in your WebCenter Portal application, then you must also configure Content Presenter to display the results of your scenarios as described in Section 19.6, "Configuring Content Presenter."

WebCenter Personalization relies on WebCenter Trust Services to provide single sign-on (SSO) between different managed servers within the WebCenter domain. Trust Services must be configured using the WLST scripts configureTrustWCPS.py and configureConnectionsWCPS.py provided in the user_projects/applications/wc_domain directory. For JDeveloper's integrated domain, only a single script (configureWCPS.py) located in the DefaultDomain/scrpts-wcps directory is used. For more information about configuring the WebCenter Trust Services and single sign-on using this script see Section 19.7, "Configuring Single Sign-on."

19.2.3 WebCenter Personalization Security

WebCenter Personalization is compatible with whatever source of user authentication services are configured within the WLS security realm. That is, it can use the default identity store and policy and credential store for the domain.

If you are using the People Connections locator or Activity Graph data providers, users must also be configured as WebCenter Spaces users.

WebCenter Personalization REST services are accessed though a pre-configured WebCenter Personalization Web application that requires authenticated access for all resources (all URIs), with the exception of the resourceIndex. You can modify these constraints to provide either less security to execute scenarios (where anonymous access is needed), or more security to prevent the ability to create new scenarios. For information about modifying the default security settings, see Section 19.8, "Overriding the Default Security Settings."

WebCenter Trust Services provides single sign-on for Personalization REST calls. This requires that the WLS TrustServicesIdentityAsserter is configured (it is not pre-configured). You can do this manually using the WLS Console or with the provided WLST scripts configureTrustWCPS.py and configureConnectionsWCPS.py located in the user_projects/applications/wc_domain directory. For JDeveloper's integrated domain, a single script (configureWCPS.py) located in the DefaultDomain/scrpts-wcps directory is used.

You can also optionally secure your WebCenter Portal application's connection to the Personalization server and Personalization providers with single sign-on. For more information about configuring single sign-on, see section Section 19.7, "Configuring Single Sign-on." Access to Property Service data can also be limited by an application using a filter (IPropertyPermission) to pre-authorize access to property data .

Scenarios can use an out-of-the-box function library supporting basic Role evaluation and testing to authorize access to scenarios.

19.2.4 WebCenter Personalization Limitations

By default, WebCenter Personalization uses a managed server-scoped cache, meaning any changes made to cached data outside the managed server will not be seen by additional installations of WebCenter Personalization.For clustered (multiple) deployments of WebCenter Personalization, Coherence may be configured for a cluster-aware cache.

19.2.5 WebCenter Personalization Configuration Options

This section describes the out-of-the-box providers and other optional extensions to WebCenter Personalization, and the configuration required to integrate them into your WebCenter Personalization project.

The out-of-the-box WebCenter Personalization data providers allow you to write scenarios and access profile data based on existing WebCenter services. These WebCenter services expose their data via RESTful web services. The Personalization data providers act as REST clients of these web services and make it easy to author scenarios within JDeveloper based on these external data sources. You can also provide your own data provider and property locator implementations to integrate your own sources of external data.

CMIS Provider

The CMIS provider is an out-of-the-box provider that you can optionally use as a data source in your Personalization project. WebCenter content services are exposed using the CMIS (Content Management Interoperability Services) standard. The CMIS REST web service runs on the WC_Spaces server and provides access (based on separate configuration choices) to the Oracle Content Server.

If a WebCenter Personalization user is also a WebCenter Spaces user, access to user content stored through the Spaces application is possible from a scenario. For more information about the Oracle Content Server, see Chapter 11, "Managing Content Repositories." For more information about configuring the CMIS provider, see Section 19.4.2, "Configuring the CMIS Provider."

Activity Graph Data Provider

The Activity Graph data provider is an out-of-the-box provider that you can optionally use as a data source in your Personalization project. WebCenter activity stream information is exposed through the Activity Graph web service. The Activity Graph REST web service runs on the WC_Spaces server and provides access to activity stream based recommendations as formed by the activity graph.

If a WebCenter Personalization user is also a WebCenter Spaces user, access to activity related recommendations (for Spaces content-types) is possible from a scenario. For more information about the Activity Graph service, see Chapter 12, "Managing the Activity Graph Service." For more information about configuring the Activity Graph provider, see Section 19.4.3, "Configuring the Activity Graph Provider."

Oracle People Connections Locator

The People Connections locator is a locator that you can optionally use as a data source in your Personalization project. WebCenter People Connections information is exposed via the People web service. The PC REST web service runs on the WC_Spaces server and provides access to social profile data as created in the context of WebCenter Spaces. If a WebCenter Personalization user is also a WebCenter Spaces user, access to People profile data is possible from a scenario. For more information about the People Connections service, see the chapter on "Integrating the People Connections Service" in the Oracle Fusion Middleware Developer's Guide for Oracle WebCenter.Unlike the other out-of-the-box data providers, the People Connection web service is accessed through the general purpose Property Service data provider using the IPropertyLocator extension interface. For more information about configuring the People Connections provider, see Section 19.4.4, "Configuring the Oracle People Connections Locator."

19.3.1 Configuring the Trust Service in the WebCenter Domain

The default WebCenter installation includes the WebCenter Personalization domain extension template, which installs two WLST python scripts (configureTrustWCPS.py and configureConnectionsWCPS.py), in the domain home:

oracle/user_projects/applications/wc_domain/scripts

These scripts and associated configureWCPS.properties file contain usage instructions. Note that these are sample scripts, and that before running the scripts, you must edit the properties file and, at a minimum, specify the ocs.server name (typically the Oracle Content Server), the spaces.server.host name, and the fmwconfig.location. These values are unique to each WebCenter installation and must be edited. Other values may also need to be changed according to the local environment (the machine port numbers, for example, may be different).

The configureConnectionsWCPS.py script sets up the default WebCenter Personalization connection information for you (i.e., connection information for Activity Graph, CMIS, and People Connections). The script relies on the WCPS.py library, which is only installed on the WebCenter domain (and not in the integrated WLS domain). You can, however, run configureConnectionsWCPS.py in the WebCenter domain and point it (using a t3 URL) to an integrated WLS domain.

You must use the oracle/as11gr1wc/common/bin/wlst.sh command file that sets up environment variables correctly (for as11gr1wc scripts).

After running the scripts, restart all servers in the domain.

Testing the Configuration

To see Trust Service single sign-on in operation, you must be calling the Conductor or Property Service from a custom JEE Web application (using the WebCenter Personalization client libraries), or be executing a scenario that uses a WebCenter Personalization connection (such as the Activity Graph or CMIS data providers), or accessing a People Connections property using the People Connections locator.

When doing any of the above, you should see the following default log entry in WC_Utilities-diagnostic.log:

[2010-11-10T07:30:40.362-08:00] [WC_Utilities] [NOTIFICATION] [] [oracle.jps.trust] [tid: [ACTIVE].ExecuteThread: '3' for queue: 'weblogic.kernel.Default (self-tuning)']
[ecid: 0000IkqQG4NBh49LJeCCyf1CqfXw000008,0] [APP: wcps-services#11.1.1.4.0] Token issue operation

You should also see the following default log entry in the WC_Spaces-diagnostic.log (if accessing services there):

[2010-11-10T07:30:40.236-08:00] [WC_Spaces] [NOTIFICATION] [] [oracle.jps.trust] [tid: [ACTIVE].ExecuteThread: '1' for queue: 'weblogic.kernel.Default (self-tuning)']
[ecid: d461d36d4a552b90:-1fe62a5d:12c365bb19b:-8000-000000000000002c,0] [APP: webcenter#11.1.1.4.0] Token validate operation.

19.3.2 Configuring the Trust Service in the Integrated WLS Domain

A separate python script is shipped with the JDeveloper installer to configure the integrated WLS domain located in the following directory:

DefaultDomain\scrpts-wcps\

This script can be run manually or using JDeveloper's Run External Script function.

Edit the properties file if you are using a non-default user or password. After creating and starting the integrated WLS domain, run the script from the scrpts-wcps directory:

Oracle\MiddlewareRC8\oracle_common\common\bin\wlst.cmd configureWCPS.py configureWCPS.properties

Restart the integrated WLS domain.

Testing the Configuration

Default logging levels are not enough to confirm token-issue and token-validate operations. Use the Configure Oracle Diagnostic Logging feature in JDeveloper and navigate to the oracle.jps.trust logger and set the level to Finest. Now run a scenario involving a custom JEE Web application calling the Conductor or Property Services.

19.3.3 Configuring Cross-Domain Trust

The Trust Service supports cross-domain trust, meaning if keystores have been created in different WLS domains, a client may allocate a token in domain 'A', issue an HTTP request with the token to domain 'B', and have the identity asserter validate and authenticate the user/request in domain 'B' through single sign-on. Note that a key assumption is that the user in domain 'A' exists in, and is the same user in domain 'B'.

By default, when running the configureWCPS.py script in the integrated WLS domain a certificate named extDomain.cer is generated. To enable cross-domain trust between the integrated WLS domain and WebCenter domain:

Copy extDomain.cer to your WebCenter (wc_domain) installation and import it there. Copy the extDomain.cer file to the scripts location:

oracle/user_projects/applications/wc_domain/scripts

Type in the following command to import the certificate:

keytool -importcert -alias orakey1 -file extDomain.cer -keystore ../../../../wlserver_10.3/wc_domain/config/fmwconfig/default-keystore.jks -storepass weblogic

Restart the servers in the WebCenter domain.

Testing the Configuration

The simplest way to validate cross domain trust is to create a People Connections WebCenter Personalization connection in the integrated WLS domain that points to the WebCenter domain's WC_Spaces server. Then, create and deploy a simple scenario to the integrated WLS domain that fetches a People Connections property value. Finally, confirm that the 'Token Validate Operation' message described above is logged on the WC_Spaces server.

19.4.1 Creating or Modifying Provider Connection Settings

This section describes how to use WLST, JConsole, Fusion Middleware Control to create or change the connection information stored in wcps-connections.xml. It also describes how you can write a custom configuration class to configure a custom provider.

This section contains the following subsections:

• Section 19.4.1.1, "Understanding WebCenter Personalization Connection Information"

• Section 19.4.1.2, "Connection Configuration Attributes"

• Section 19.4.1.3, "Configuring Connections Using WLST"

• Section 19.4.1.4, "Configuring Connections Using JConsole"

• Section 19.4.1.5, "Configuring Connections Using Fusion Middleware Control"

• Section 19.4.1.6, "Writing a Custom Configuration Class"

<domain directory>/config/fmwconfig/wcps-connections.xml

19.4.2 Configuring the CMIS Provider

If you are working outside of the Integrated WLS domain (i.e., in the WC_Spaces domain), before you can use the CMIS provider in your scenario, you must first configure connection settings for it.

Connection settings for the CMIS provider are maintained in wcps-connections.xml in the wc_domain conductor extensions directory (domain scoped). Although it is not recommended that you edit this file directly, there are several other ways in which you can modify connection settings. Use one of the methods described in Section 19.4.1, "Creating or Modifying Provider Connection Settings." to configure the connection settings for the CMIS provider.

Connection Element and Property Descriptions

<connection-name> - unique name for this connection. Connections can be retrieved by name.

<namespace> - generally, this must match the namespace the accessing scenario is deployed within. The namespace is how the Conductor determines how to locate the appropriate <connection> for a given scenario. Using a wildcard '*', you can make this connection element available in all namespaces.

<name>isDefault</name> - marks this connection as the default connection (if multiple connections are defined)

<name>repositoryId</name> - this property must be changed to match the Content Repository in your environment.

<name>path</name> - this property must be changed to match the Content Repositor in your environment. Defaults to /api/cmis/repository/repositoryId if not specified

<name>scheme</name> - protocol to access the CMIS REST service (HTTP or HTTPS for SSL). Defaults to HTTP if not explicitly specified.

<name>host</name> - machine name hosting the CMIS REST service. This is the machine name of the WC_Spaces managed server.

<name>port</name> - machine port number hosting the CMIS REST service. This is the machine port number of the WC_Spaces managed server.

<name>pathTrim</name> - Default is no trim if not explicitly specified

<name>rewriteUrls</name> - can be set to None, Consumer, or Producer. See the REST Proxy page for details. If you want the direct URLs (from the CMIS server for document links), set this to None. Default is no rewrite (None).

<name>username</name> - (Optional) the username to use when connecting to the CMIS REST service. Can be used to force a connection to a fixed username.

<name>password</name> - (Optional) the password to use when connecting to the CMIS REST service. Used in conjunction with username, can be used to force a connection to a fixed username/password. Not recommended for use outside of development environment since password access is not secured.

<name>timeoutInMillisecs</name> - Time in milliseconds before the CMIS query read response times out

<name>propagateTimeoutExceptions</name> - If true, propagate the timeout exceptions. Otherwise, log the exception and return null for the CMIS query response.

19.4.3 Configuring the Activity Graph Provider

If you are working outside of the Integrated WLS domain (i.e., in the WC_Spaces domain), before you can use scenarios that rely on the Activity Graph provider, you must configure connection information for your local environment.

Connection settings for Activity Graph are maintained in wcps-connections.xml in the wc_domain conductor extensions directory (domain scoped). Although it is not recommended that you edit this file directly, there are several other ways in which you can modify connection settings. Use one of the methods described in Section 19.4.1, "Creating or Modifying Provider Connection Settings." to configure the connection settings for the Activity Graph provider.

Connection Element and Property Descriptions

<connection-name> - unique name for this connection. Connections can be retrieved by name.

<namespace> - generally, this must match the namespace the accessing scenario is deployed within. The namespace is how the Conductor determines how to locate the appropriate <connection> for a given scenario. Using a wildcard '*', you can make this connection element available in all namespaces.

<name>isDefault</name> - marks this connection as the default connection (if multiple connections are defined)

<name>scheme</name> - protocol to access the CMIS REST service (HTTP or HTTPS for SSL). Defaults to HTTP if not explicitly specified.

<name>host</name> - machine name hosting the Activity Graph REST service. This is the machine name of the WC_Spaces managed server.

<name>port</name> - machine port number hosting the Activity Graph REST service. This is the machine port number of the WC_Spaces managed server.

<name>rewriteUrls</name> - can be set to None, Consumer, or Producer. See the REST Proxy page for details. If you want the direct URLs (from the CMIS server for document links), set this to None. Default is no rewrite (None).

<name>user</name> - (Optional) the username to use when connecting to the Activity Graph REST service.

<name>password</name> - (Optional) the password to use when connecting to the Activity Graph REST service. Used in conjunction with username, can be used to force a connection to a fixed username/password. Not recommended for use outside of development environment since password access is not secured.

<name>restResourceIndex</name> - the URI suffix to append to the host/port for the REST resource index (for example: '/rest/api/resourceIndex')

19.4.4 Configuring the Oracle People Connections Locator

If you are working outside of the Integrated WLS domain (i.e., in the WC_Spaces domain), before you can use scenarios that rely on the People Connections locator, you must configure connection information for your local environment.

The Property Service uses an IPropertyLocator (the People Connections ILocator) to interface with the WebCenter People Connections service. The Property Provider that interfaces with the WebCenter People Connections service uses this ILocator to make PC REST calls for a given user (or self) and return the 'Person' object represented by that REST service call. The Person attributes represent values for that WebCenter profile.

Connection settings for the People Connections ILocator are maintained in wcps-connections.xml in the wc_domain conductor extensions directory (domain scoped). Although it is not recommended that you edit this file directly, there are several other ways in which you can modify connection settings. Use one of the methods described in Section 19.4.1, "Creating or Modifying Provider Connection Settings." to configure the connection settings for the People Connections ILocator.

Connection Element and Property Descriptions

<connection-name> - unique name for this connection. Connections can be retrieved by name.

<namespace> - generally, this must match the namespace the accessing scenario is deployed within. The namespace is how the Conductor determines how to locate the appropriate <connection> for a given scenario. Use a wildcard '*' to make this connection element available in all namespaces.

<name>isDefault</name> - marks this connection as the default connection (if multiple are defined)

<name>scheme</name> - protocol to access the CMIS REST service (HTTP or HTTPS for SSL). Defaults to HTTP if not explicitly specified.

<name>host</name> - machine name hosting the PC REST service. This is the machine name of the WC_Spaces managed server.

<name>port</name> - machine port number hosting the PC REST service. This is the machine port number of the WC_Spaces managed server.

<name>user</name> - (Optional) the username to use when connecting to the People Connection REST service. Can be used to force a connection to a fixed username.

<name>password</name> - (Optional) the password to use when connecting to the People Connections REST service. Used in conjunction with username, can be used to force a connection to a fixed username/password. Not recommended for use outside of development environment since password access is not secured.

<name>restResourceIndex</name> - appended to the PC REST service host/port, pointing to the location of the resourceIndex (available REST services) page (for example: '/rest/api/resourceIndex')

Bootstrapping the Person class to the Properties Provider

In order for the Property Service to know about and use the results of the People Connections REST calls, it needs to know about a 'Person'. This means creating a 'Person' property set definition, along with its individual attributes set as property definitions, before a 'Person' can be instantiated and its properties set.

The People Connection ILocator code does this by bootstrapping that process in a servlet listener, configured in its web.xml file as shown in the example below:

<?xml version="1.0" encoding="UTF-8" ?>
<web-app xmlns="http://java.sun.com/xml/ns/j2ee" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
    xsi:schemaLocation="http://java.sun.com/xml/ns/j2ee http://java.sun.com/xml/ns/j2ee/web-app_2_4.xsd"
    version="2.4">
 
    <!-- Allows connection config classes to be loaded from the connections.xml file -->
     <listener>
      <listener-class>oracle.wcps.connection.lifecycle.VersatileModuleLifecycleCallback</listener-class>
    </listener>
 
     <listener>
      <listener-class>oracle.wcps.people.util.BootstrapPropertiesListener</listener-class>
    </listener>
 
</web-app>

Accessing the PC REST connection configuration information

Because the People Connections ILocator is not an actual 'provider', you cannot access its connection information in provider code, as for example Activity Graph. Instead, internal code uses the VersatileModuleLifecycleCallback class to make that configuration information available, and consequently makes this is a required listener to be configured in web.xml. Once that listener has been activated, the code can make calls to access connection information and parameterize the ILocator code to point to the PC REST server.

Tying the PC ILocator to the Properties Service Provider

The Properties Service Provider (PSP) knows about the People Connections ILocator through the namespaces. In the bootstrapping process above, the PropertySetDefinition (and its definitions) are namespaced with "people.connections.person" and a locator class "oracle.wcps.people.property.PeoplePropertyLocator". In using the PSP, the namespace and PropertySetDefinition are passed to the PSP. The PSP uses the locator class defined in the PropertySetDefinition to instantiate and delegate to property values (Person values from the People Connections REST service).

The locator and namespaces are critical in this process. They are defined as constants in the internal PropertyDefConstants class. Note that these do not need to be configured.

19.4.5 Configuring Custom Providers

Connection settings for Activity Graph are maintained in wcps-connections.xml in the wc_domain conductor extensions directory (domain scoped). Although it is not recommended that you edit this file directly, there are several other ways in which you can modify connection settings. Use one of the methods described in Section 19.4.1, "Creating or Modifying Provider Connection Settings." to configure the connection settings for your custom provider. Refer to Section 19.4.1.2, "Connection Configuration Attributes" for information about the configuration file elements and property descriptions.

19.6.1 Configuring the WebCenter Application's Content Server Connection

For a WebCenter Portal application, use JDeveloper to set up the URL connection, or set the Content Presenter task flow parameters as described in Section 19.6.2, "Configuring the Content Presenter Task Flow Parameters." For WebCenter Spaces, you can use either WLST commands or Fusion Middleware Control to configure the connection.

This section contains the following subsections:

• Section 19.6.1.1, "Configuring WebCenter Spaces Connections Using WLST"

• Section 19.6.1.2, "Configuring WebCenter Spaces Connections Using Fusion Middleware Control"

adf_createHttpURLConnection('webcenter','Conductor','http://example.com:8891/wcps/api/conductor?namespace=CP_namespace&

19.6.2 Configuring the Content Presenter Task Flow Parameters

You can configure a Content Presenter instance through its task flow parameters. These can either be set at runtime in the Content Presenter Configuration dialog, or from JDeveloper as you add the Content Presenter task flow. To do this manually, you need to set two parameters: the Data Source Type parameter must be set to dsTypeScenarioResults, and the Data Source parameter should be set to something like:

conductor-connection-name=ConductorConnectionName,namespace=ScenarioNamespace,scenario-name=ScenarioName,inputparam1=value1,inputparam2=value2

Note that the conductor-connection-name value must match with a URL connection that points to a valid Conductor server. Also, the namespace used should be the name of the namespace to which the specified scenario belongs. Finally, any input parameters that the scenario may be expecting can appended (as shown above), with a comma separating the name/value pairs.

For more information about configuring Content Presenter for WebCenter Personalization, see:

• At runtime: "Setting Content Presenter Task Flow Properties" in the Oracle Fusion Middleware User's Guide for Oracle WebCenter

• In JDeveloper: "Content Presenter Task Flow Parameters and Out-of-the-Box Display Templates" in Oracle Fusion Middleware Developer's Guide for Oracle WebCenter.

19.6.3 Configuring the Conductor's Scenario Tags

On the Conductor side, your Scenarios must have the correct tag in order for Content Presenter to see them. Content Presenter uses the tag ContentPresenterScenario, so any scenarios you want Content Presenter to pick up must have this tag associated with them.

Once you have everything set up on both the Conductor and WebCenter application side, everything else is fairly simple. When you open the Content Presenter Configuration dialog at runtime, the Content Source selection list displays Results of a Scenario. Selecting this displays a table of all of the scenarios that have been tagged for Content Presenter consumption. The first Scenario is always selected, and if it has any Input Parameters defined, they will be displayed below the table with input fields.

As you select scenarios in the table, the Input Parameters below will be updated. After selecting a scenario and specifying any input parameters, you can either preview or save Content Presenter to get the results. The results will be displayed much like any other multi-valued content source and will ultimately depend on the template selected for display purposes.

19.8.1 Allowing Anonymous Execution of Scenarios

Adding the following security constraint to the domain's conductor-extensions-library\WEB-INF\web.xml, file will honor default descriptor (authentication required) security, plus allow anonymous GET/POST on scenarios created or deployed from an anonymous application or namespace:

<security-constraint>
  <web-resource-collection>
    <web-resource-name>ConductorJerseyWebApplication</web-resource-name>
    <url-pattern>/api/conductor/namespaces/anonymous/scenarios/*</url-pattern>
    <http-method>GET</http-method>
    <http-method>POST</http-method>
  </web-resource-collection>
  <!-- Allow anonymous user access&nbsp; in this namespace -->
  <!--auth-constraint>
     <role-name>Users</role-name>
   </auth-constraint-->
</security-constraint>

19.8.2 Disabling Scenario Creation by Anonymous Users

You can disable scenario creation for any anonymous user using a simple filter that you add to the domain's conductor-extensions-library\WEB-INF\web.xml file. An example filter (AnonymousScenarioFilter) is shown below:

<filter>
    <filter-name>AnonymousScenarioFilter</filter-name>
    <filter-class>oracle.wcps.samples.AnonymousScenarioFilter</filter-class>
  </filter>
  <filter-mapping>
    <filter-name>AnonymousScenarioFilter</filter-name>
    <url-pattern>/api/conductor/namespaces/PublicPersonalization/scenarios</url-pattern>
  </filter-mapping>
  <security-constraint>
      <web-resource-collection>
          <web-resource-name>ConductorJerseyWebApplication</web-resource-name>
          <url-pattern>/api/conductor/namespaces/PublicPersonalization/scenarios/*</url-pattern>
          <http-method>GET</http-method>
          <http-method>POST</http-method>
      </web-resource-collection>
      <!--
        Commented out to allow anonymous user access  in this namespace
      <auth-constraint>
      <role-name>Users</role-name>
      </auth-constraint>
      -->
  </security-constraint>

The filter explicitly checks for an anonymous user (httpRequest.getUserPrincipal() == null) and an HTTP POST operation on the /api/conductor/namespaces/PublicPersonalization/scenarios URL, which is the REST resource for creating a scenario.

public void doFilter(ServletRequest request, ServletResponse response, FilterChain chain)
        throws IOException, ServletException
    {
        if (request instanceof HttpServletRequest)
        {
            HttpServletRequest httpRequest = (HttpServletRequest)request;
            String method = httpRequest.getMethod();
            if ("POST".equalsIgnoreCase(method) && httpRequest.getUserPrincipal() == null)
            {
              throw new ServletException("Anonymous users cannot create scenarios.");
            }
        }
        chain.doFilter(request, response);
    }

19.8.3 Disabling Scenario Creation by Authenticated Users

A simple change to the filter described in Section 19.8.2, "Disabling Scenario Creation by Anonymous Users" (removing the httpRequest.getUserPrincipal() check) would disable scenario creation for all users. Although the HTTP POST operation is also used to request execution of scenarios, the URI in that case is different (and protected in the <security-constraint> not the filter <url-pattern>).