Configuring TIBCO WebFOCUS Security

In this section:

In the Administration Console, you configure the security settings that govern authentication and authorization in your environment.

Security can either be configured internally in the Repository, or externally in a directory that is not part of TIBCO WebFOCUS. To configure settings for internal security, use the settings in the Internal page. To configure a connection to an external directory that is not part of TIBCO WebFOCUS, such as Microsoft Active Directory or LDAP Directory, use the External page.

Understanding Internal Security Page Settings

How to:

Internal authentication and authorization are enabled, by default. Optionally, you can use the settings in the Internal page to configure sign in and password policies.

Sign In Settings (Enable Sign In Settings)

Determines the default values assigned to the Sign In Settings on the Internal Security Page.

This check box is cleared (False), by default. Sign In Settings are inactive and unavailable and display a value of 0.

When this check box is selected (True), Sign In Settings are activated, automatically assigned a set of pre-configured values, and made available for updates. To deactivate an individual setting while this check box is selected, type or select zero (0). When this check box is later cleared, all values assigned to the Sign In Settings return to 0, and the settings are deactivated.

This setting does not affect the value or availability of the Password Expiration Result options.

Maximum Sign-in Attempts (IBI_Max_Bad_Attempts)

Specifies the number of unsuccessful sign-in attempts allowed before the account status is changed to locked. When the Sign In Settings check box is cleared, the default value is 0, which allows unlimited attempts. When the Sign In Settings check box is selected, the default value is 5, and administrators can type or select an alternative value. To deactivate this setting when the Sign In Settings check box is selected, type or select 0.

Lockout Duration (Minutes) (IBI_Account_Lockout_Duration)

Specifies the number of minutes before the status of an account changes from locked to active. When the Sign in Settings check box is cleared, the default value is 0 (off). When the Sign In Settings check box is selected, the default value is 3 minutes, and administrators can type or select an alternative value. To deactivate this setting when the Sign In Settings check box is selected, type or select 0.

Lockout Duration Reset (Minutes) (IBI_Account_Lockout_Duration_Reset)

Specifies the number of minutes that must elapse after the number of failed sign-in attempts specified by the Maximum Sign in Attempts setting before the allowed sign-in attempt counter is reset to 0. The available range is from 1 to 99,999 minutes. When the Sign In Settings check box is cleared, the default value is 0 (off). When the Sign In Settings check box is selected, the default value is 3 minutes, and administrators can type or select an alternative value. To deactivate this setting when the Sign In Settings check box is selected, type or select 0.

Days Until Password Expires (IBI_Password_Expire)

Specifies the number of days that a password will remain active. When the Sign In Settings check box is cleared, the default value is 0, which prevents passwords from expiring. When the Sign In Settings check box is selected, the default value is 90 days. Once the password has expired, the user must take the action specified by the Password Expiration Result (IBI_Password_Expire_Action) setting, and administrators can type or select an alternative value. To deactivate this setting when the Sign In Settings check box is selected, type or select 0.

Days Until Password Expiration Warning (IBI_Password_Expire_Warning)

Specifies the number of days prior to expiration that a warning will be displayed to the user. When the Sign In Settings check box is cleared, the default value is 0, which provides no warning. When the Sign In Settings check box is selected, the default value is 75 days. This value should be less than or equal to the value assigned to the Days Until Password Expires (IBI_Password_Expire) setting, and administrators can type or select an alternative value. To deactivate this setting when the Sign In Settings check box is selected, type or select 0.

Password Expiration Result (IBI_Password_Expire_Action)

Specifies the action required when a password expires. You can choose one of the following options:

  • To force users with expired passwords to change their passwords before signing in. (MUSTCHANGE) This is the default value.
  • Change the status of users with expired passwords to inactive. Such users cannot sign in until an administrator resets the password. (DISABLE-USER)
Enable Password Complexity (IBI_Password_Complexity)

Determines the default values assigned to the Password Settings on the Internal Security Page.

This check box is cleared (False), by default. All of the Password Settings are inactive and unavailable and display a value of 0.

When this check box is selected (True), all of the Password Settings are activated and available for updates. WebFOCUS automatically assigns a pre-configured set of values to them.

When this check box is later cleared, all values assigned to the Password Settings return to 0, and the settings are deactivated.

If this check box is selected (True), passwords also must:

  • Not contain the user account name or parts of the full name of the user that exceed five consecutive characters.
  • Be at least six characters long or at least the number of characters specified in Minimum Password Length, whichever is greater.
  • Contain characters from three of the following four categories:
    • Uppercase English characters (A through Z).
    • Lowercase English characters (a through z).
    • Base 10 digits (0 through 9).
    • Non-alphabetical characters (for example, !, $, #, %).
    • Complexity requirements are enforced when passwords are changed or created.
Minimum Password Length (IBI_Password_Minimum_Length)

Defines the required minimum length of a password. When the Enable Password Complexity check box is cleared, the default value is 0 characters. When the Enable Password Complexity check box is selected, the default value is 6 characters. To deactivate this setting when the Enable Password Complexity check box is selected, type or select 0.

Password Reuse (IBI_Password_Reuse)

Specifies the number of recent passwords that cannot be reused. If Password Reuse is set to 6, for example, the 6 most recent password changes are tracked, and you are prevented from reusing them when creating a new password. When the Enable Password Complexity check box is cleared, the default value is 0 changes, and users can re-use any previously-assigned password. When the Enable Password Complexity check box is selected, the default value is 2 changes. To deactivate this setting when the Enable Password Complexity check box is selected, type or select 0.

Procedure: How to Configure Sign In Settings

  1. In the Administration Console, click the Security tab.
  2. On the Security page, under the Security Configuration folder, click Internal.
  3. Select the Sign In Settings check box.

    The Internal page displays the following default values:

    • Maximum Sign-in Attempts – 5
    • Lockout Duration (Minutes) – 3
    • Lockout Duration Reset (Minutes) – 3
    • Days Until Password Expires – 90
    • Days Until Password Expiration Warning – 75
  4. To change the default value assigned to any of these settings, type or select an alternate value in any of these boxes.
  5. To clear all settings, clear the Sign In Settings check box. All values automatically return to 0.
  6. In the Password Expiration Result section, accept the default option To force users with expired passwords to change their passwords before signing in, or click the alternative option Change the status of users with expired passwords to inactive. Such users cannot sign in until an administrator resets the password.
  7. Continue with any other Internal Security page updates or save your changes.

Procedure: How to Configure Password Settings

  1. In the Administration Console, click the Security tab.
  2. On the Security page, under the Security Configuration folder, click Internal.
  3. Select the Enable Password Complexity check box.

    The Internal page displays the following default values:

    • Minimum Password Length – 6
    • Password Reuse - 2
  4. To change the default value assigned to any of these settings, type or select an alternate value in either of these boxes.
  5. To clear all settings, clear the Password Settings check box. All values automatically return to 0.
  6. Continue with any other Internal Security page updates or save your changes.

Procedure: How to Save Internal Security Page Configuration Updates

  1. When all of your Internal Security Page Configuration updates are complete, click Save.
  2. When you receive a confirmation message, click OK.
  3. When you receive a message to clear the cache, click OK.
  4. In the Administration Console menu bar, click Clear Cache and, when you receive a confirmation message, click OK.

Understanding External Security Page Settings

Use the External page if you configure security in a directory that is not part of TIBCO WebFOCUS.

Enable External Security

When you select this check box, internal security settings are overridden and all authentication activities and approvals are directed to the external system you identify on this page. Fields and features in the section below this check box become available and respond to updates from Administrators.

External Security Type (IBI_Authentication_Type)

The list box for this field contains the following values:

  • Reporting Server. Definition is currently unavailable.
  • Legacy LDAP. Authenticates users against an AD or LDAP directory. Do not select this option unless advised to do so by the Customer Support Team.
  • Custom Java Plug-In. Definition is currently unavailable. Do not select this option unless advised to do so by the Customer Support Team.
Reporting Server Node

Specifies the name of the Server that manages communications with the external authentication provider application.

Server Administrator ID

Specifies the ID of the administrator of the external security server. To make the User Authorization section available, you must type the ID of a valid user that is already defined on the external security server in this field. Typically this is the user ID you assign to the server manager during the installation.

Password

Specifies the Password assigned to the administrator of the external security server. To validate the ID and password of the external Server administrator, click Connect. When you submit a valid ID and password, the User Authorization section becomes available.

User Authorization

The location where authorization is granted to users. The options and check boxes in this section become available only after you type a valid user ID in the Server Admin ID field and click Connect.

  • Internal. TIBCO WebFOCUS manages all user authorization tasks.
  • Internal and External. TIBCO WebFOCUS and the external application share the management of authorization tasks.
  • External Only. The external application manages authorization tasks.
  • Group Provider Override. When selected, this check box and the field associated with it identify the external provider that overrides group authorization.

    Note: This check box appears only after you click the options Internal and External, or External Only, the Group provider Override checkbooks and field appear.

Account Creation on Sign In

Specifies the range of user accounts that will be created upon their first sign-in attempt.

  • All. Specifies the creation of an account for all users upon their first sign-in attempt.
  • Mapped External Groups. Specifies the creation of an account only for those users in Mapped External Groups upon their first sign-in attempt.
  • Off. Disables the automatic creation of user accounts.
Synchronize User Information

Activates the automatic retrieval of user information for the Description and EMail Address fields when users sign in to TIBCO WebFOCUS, helping to ensure that the most current user information is always available.

If this check box is cleared, the default setting, the Description and EMail Address fields of a user are not updated when that user signs in.

If this check box is selected, the Description and EMail Address fields of a user are updated when that user signs in. The source of this information depends upon the selection of one of the following options:

  • With Authentication Provider. If this option is selected, updated Description and EMail Address field information is received from the authentication provider. This option is selected, by default.
  • With Authorization Provider. If this option is selected, updated Description and EMail Address field information is received from the authorization provider.

The values assigned to this setting apply equally to users who sign in to a security zone using Form Based authentication as well as Pre-authentication, as long as External Security is in use.

Using Advanced Settings

The Advanced page in the Security tab of the Administration Console provides access to settings that identify specialized administrative user IDs and passwords and additional security features that apply to the entire WebFOCUS installation.

Settings on the Advanced page identify the ID of the Anonymous User, which is invoked when users select the Public Access link from the sign-in screen. Settings on this page also identify the ID and password of the Root User, who is the Superuser that maintains unlimited access to WebFOCUS. The Root User serves as a fallback when all other users are locked out or whenever a user with all-access permissions is required to maintain system operations.

Multiple Sign-ins Per User (IBI_MULTIPLE_LOGINS_PER_USER)

Specifies whether the same user can have multiple sign-ins, which are authenticated sessions, open simultaneously. When this check box is selected, (True), a user can have multiple authenticated sessions open simultaneously. When it is cleared, (False), a user can have only one authenticated session open at a time.

The ability to maintain multiple open authenticated sessions per user is available only in the Enterprise Edition of WebFOCUS. Other editions allow only one open authenticated session per user.

  • In the Enterprise Edition, this check box is selected (True), by default.
  • In all other editions, this check box is cleared (False), by default, and is unavailable.
Root User (IBI_ADMIN_NAME)

Specifies the user ID of the administrator or superuser. When Root User (IBI_Admin_Name) and Root Password (IBI_Admin_Pass) are set, this user is given ALL permissions, regardless of other policies set within the system. Typically, this user ID is used under limited circumstances and removed when no longer needed.

Root Password (IBI_ADMIN_PASS)

Specifies the password of the administrator or superuser.

Reporting Server Anonymous User ID (IBI_ANONYMOUS_WFRS_USER)

Specifies the user ID that the WebFOCUS Client uses to connect to the Server for anonymous, or unauthenticated, requests. Used when you sign in as a Public User. For more information on configuring the Server, see TIBCO WebFOCUS Server Settings.

Reporting Server Anonymous Password (IBI_ANONYMOUS_WFRS_PASS)

Contains the password used by the anonymous user for connections to the Server. This applies to all authentication types. Used when you sign in as a Public User.

Anonymous User ID (IBI_ANONYMOUS_USER)

Specifies the user ID that the WebFOCUS Client uses for unauthenticated requests. By default, the value is public.

By default, the WebFOCUS Client supports anonymous, or unauthenticated, access to resources made available to users in the Anonymous group, as well as to procedures on the WebFOCUS Server. The Server credentials used by this setting are specified by Reporting Server Anonymous User ID (IBI_WFRS_Anonymous_User) and Reporting Server Anonymous Password (IBI_WFRS_Anonymous_Pass).

Note: This setting is relevant only to the Enterprise Edition, which is the only edition that supports anonymous user access.

Anonymous External User (IBI_ANONYMOUS_EXTERNAL_USER)

If set, specifies the user ID used to obtain authorization for the anonymous user from an external security provider.

Note: This setting is relevant only to the Enterprise Edition, which is the only edition that supports anonymous user access.

Named Anonymous User (IBI_NAMED_ANONYMOUS_USERS)

When this check box is selected (True) and your installation of WebFOCUS uses an external or pre-authentication method, named anonymous users are allowed. If the user is not in the repository and does not pass the IBI_ALLOW_LOGIN_EXTERNAL_GROUPS setting, the sign-in will complete, and the user will have the same authorization as a public user within WebFOCUS. The user will not be added to the database and cannot be added to any groups or be shared with. Such users are considered public users within WebFOCUS, although their user IDs will be tracked in the session monitor. Authorization on the Server is based on the explicit user ID. The default value is False (check box cleared).

If the user is registered in WebFOCUS, but no longer passes the IBI_ALLOW_LOGIN_EXTERNAL_GROUPS setting, the user will still be treated as a named anonymous user.

Note: This setting is relevant only to the Enterprise Edition, which is the only edition that supports anonymous user access.

Enable Password Change (IBI_USER_PASSWORD_CHANGE)

The default value is True (check box is selected), which enables users to change their own passwords. You may wish to disable this ability under certain circumstances. For example, your system may authenticate users against an external system that will not allow them to change their passwords through WebFOCUS.

Add Namespace When Creating Users by Group Administrators (IBI_USER_NAMESPACE)

Used for multi-tenant implementations, where group administrators are allowed to create users for the groups they administer. This setting specifies whether or not a namespace is added as a prefix or suffix to user names when created by a group administrator.

  • When set to (NONE), the default setting, user names do not include a namespace.
  • When set to PREFIX, the namespace, followed by a slash (\), precedes the user name.

    For example, if a Group Administrator signs in as tenant1\groupadmin, tenant1 is the namespace for this Group Administrator and all of the users for whom this Group Administrator is responsible. When creating users, the namespace of the Group Administrator is automatically prepended to all new user names when created: tenant1\username.

  • When set to SUFFIX, the namespace, preceded by an at sign (@), follows the user name.

    For example, if a Group Administrator signs in as groupadmin@tenant1.com, the namespace of the Group Administrator is tenant1.com. The namespace of the Group Administrator is appended to all new user names when created: username@tenant1.com.

The additional level of identification provided by the use of a namespace helps prevent conflicts when the same name is assigned to users in more than one group, and supports SaaS installations that assign users to multiple Tenant Groups.

Configuring Security Zones

In this section:

The Security Tab enables you to configure the type of pre-authentication to use for each of the four security zones. Pages under the Security folder enable you to view and update the configuration for each Security Zone.

The four zones are:

Understanding the Default Zone Configuration

The Default Zone establishes the type of authentication for most users.

By default, the Authentication page in the Default Zone is configured to accept Form Based and Anonymous Authentication settings. Form Based security can be based on Internal Portal Security or External Security (WFRS). The Form Based setting presents users with a Sign in page whenever they open WebFOCUS. The public user defined in the Anonymous Authentication profile permits WebFOCUS to accept all users with or without passwords. This default configuration accommodates the broadest range of users. However, Administrators can enable or disable any of the authentication methods on this page to upgrade this configuration to a level of authentication that best supports their requirements.

By default, the Request Matching page in the Default Zone is configured to accept all Request URL Patterns and IP Address Patterns. The Request Matching page should not be changed, but you can modify the IP Addresses to use for this default zone.

Understanding the Mobile Zone Configuration

The Mobile Zone offers authentication methods tailored to the higher level of security required by users who access WebFOCUS from mobile devices. This zone allows Administrators to use one of the established authentication methods within WebFOCUS for Mobile users.

The Authentication page in the Mobile Zone is configured to accept Form Based and Remember-Me settings, by default. These settings present users with a Sign in page whenever they open WebFOCUS and the Remember-Me Authentication profile permits WebFOCUS to allow users to maintain trusted access to WebFOCUS through multiple sessions. Administrators can enable or disable any of the authentication methods on this page.

The Request Matching page in the Mobile Zone limits URL Requests to two patterns, /Mobile Controller/**, and /Mobile Favs Controller/**. Neither URL Request patterns nor IP Addresses can be added, removed, or edited.

Understanding the Portlet Zone Configuration

The Portlet Zone offers authentication methods tailored to the higher level of security required by remote users who access WebFOCUS from WebFOCUS Open Portal Services products, including SharePoint.

The Authentication page in the Portlet Zone is configured to accept Form Based and Remember-Me settings, by default. These settings present users with a Sign in page whenever they open WebFOCUS and the Remember-Me Authentication profile permits WebFOCUS to allow users to maintain trusted access to WebFOCUS through multiple sessions. You can enable or disable any of the authentication methods on this page.

The Request Matching page in the Portlet Zone limits URL Requests to a single pattern, /tool/portlets/**. Neither URL Request patterns nor IP Addresses can be added, removed, or edited.

Understanding the Alternate Zone Configuration

The Alternate Zone allows Administrators to sign in using a different method of authentication from the Default Zone. Administrators can use the Alternate Zone to customize the methods of authentication that can be used to support users.

The Authentication page in the Alternate Zone is configured to accept Form Based Authentication, by default. This setting presents users with a Sign in page whenever they open a session. You can enable or disable any of the authentication methods on this page. To establish an alternate method of authentication, disable the two default methods, and enable a method that is not in use in the default zone.

The Request Matching page in the Alternate Zone permits you to add URL Request Patterns and IP Address Patterns to limit the range of valid URLs to support authentication. By default, the URL Request Patterns page displays the pattern, /**, that accepts any and all URL layouts. The IP Address pattern page displays three patterns, 127.0.0.1, 0:0:0:0:0:0:0:1, and, ::1, all representations of the LocalHost IP address in IPV4 and IPV6 respectively.

Enabling Security Zones

How to:

All security zones except the Alternate Zone are enabled, by default. You must enable the Alternate Zone to use it. To enable a Security Zone, change the status of that zone on the Security Zones page from Disabled to Enabled.

Procedure: How to Enable a Security Zone

  1. On the Security Zones Page, click anywhere in a Security Zone entry marked Disabled, and then, in the Actions section, click Enable.

    The status changes from Disabled to Enabled, and the Security Zone is ready for use.

Working With the Authentication Page

In this section:

How to:

The Authentication page defines the methods of authentication available within a security zone. The default settings for each zone identify the most commonly used authentication methods for users in that zone, but Administrators can replace or supplement them with any of the other methods on the Authentication page.

Each available authentication method requires a unique configuration and works in different ways to authenticate users. Authentication methods that are available to users within a specific zone are identified with a check mark and a status of Enabled. Methods that are not available are marked with a status of Disabled.

The Actions section of the Authentication page contains links to the dialog boxes and activities that affect all Authentication methods in a particular zone. The Security Zones section contains links that save, export, or import Authentication page settings.

The Options link opens the Authentication Options dialog box where administrators can identify a customized URL to which WebFOCUS can direct users after their logout.

The Key Management link opens the Key Management dialog box where administrators can configure the location of the Keystore file that identifies the secure keys that support certificate-based methods of authentication, such as SAML and Trusted Ticket.

The Cross-Origin Settings link opens the Cross-Origin Settings dialog box, where administrators can configure WebFOCUS to allow the use of its resources in external applications that take advantage of WebFOCUS business intelligence by embedding WebFOCUS content and resources into their webpages. Within this dialog box, the Allow Embedding check box supports the embedding of WebFOCUS resources in the webpages of comma-delimited whitelisted URLs. The Allow Cross-Origin Resources Sharing (CORS) check box supports the use of Ajax request and response messages that enable users of comma-delimited whitelisted URLs to interact with embedded WebFOCUS resources. Each zone maintains its own configuration of cross-origin settings.

The Enable/Disable link enables previously disabled authentication methods, and disables previously enabled methods. This link becomes available only after an authentication method is selected.

The Edit link opens the dialog box that supports a selected Authentication Method. In that dialog box, you can create or update the configuration settings required by that method. This link becomes available only after an authentication method is selected.

Procedure: How to Enable an Authentication Method

  1. On the Authentication Page, right-click the Name or Status section of an Authentication Method entry marked Disabled, and then click Enable.

    or

  2. Click anywhere in an Authentication Method entry marked Disabled, and then, in the Actions section, click Enable.

    The status changes from Disabled to Enabled with a check mark, and the method of authentication represented by that entry is available for use within the Security Zone.

Procedure: How to Disable an Authentication Method

  1. On the Authentication Page, right-click the Name or Status section of an Authentication Method entry marked Enabled, and then click Disable.

    or

  2. Click anywhere in an Authentication Method entry marked Enabled, and then, in the Actions section, click Disable.

    The status changes from Enabled to Disabled, the check mark clears, and the method of Authentication represented by that entry is no longer available for use within the Security Zone.

Procedure: How to Save Changes to the Authentication Page

  1. On the Authentication Page, in the Actions section, under Security Zones, click Save.
  2. When you receive a confirmation message, click OK.
  3. When you receive a message to reload the web application, click OK.
  4. Sign out of your current session, sign in again as an administrator, and return to the Administration Console.
  5. Click the Security Tab, and under the Security ZoCross-ne Folder, click the Authentication Page for the zone that you recently configured.

    Your new or updated settings appear as configured.

Procedure: How to Configure a Custom Logout Address

Security Zones are configured to use form-based authentication, by default. When users in a form-based authentication security zone sign out, the Sign out page that opens links users to the Sign in page. However, in zones that use an external authentication method or a pre-authentication method, there is no need to link users to the Sign in page after they sign out. For these zones, the Custom Logout Address substitutes the URL of an alternative sign-out page that overrides the display of the default Sign out page.

  1. On the Authentication page, in the Actions section, click Options.
  2. In the Authentication Options dialog box, select the Enable custom logout target URL check box.
  3. Type the custom logout target URL.
    • If the Security Zone is configured for Integrated Windows Authentication (IWA), accept the default sign-out URL, /signout.
    • If the Security Zone is configured for another third party pre-authentication provider, type the sign-out URL that ends the SSO product session for that provider, if one exists. For example, the sign-out URL for WebSEAL may be:
      http://webseal.domain.com/pkmslogout

      The sign-out URL for Siteminder may be: 

      http://siteminder.domain.com/logout.html

      To return a user working in a single sign on environment to his or her original portal automatically, leave the final term blank. For example, the sign-out URL for WebSEAL would then be: 

      http://webseal.domain.com
  4. Click OK.

Managing the Allowed Host Names List

How to:

In WebFOCUS internal communications, user requests move from browsers to the WebFOCUS Server in the form of HTTP Request messages. By convention, HTTP Request messages must identify the URL of the virtual host, which is the application or website hosted on the server that will process the request, in their Host Header field. Messages from legitimate users identify the URL of an existing host on their targeted server. However, messages from potential attackers can identify URLs for hosts that do not exist on the targeted server.

Servers that do not require the authentication of the host header URL of incoming HTTP Request messages typically direct those that contain the URL of an undefined host to the first available host application for processing. That host then processes the message containing the unrecognized URL, substitutes it for the legitimate URL in the Location field in the Web Cache, and returns messages containing this poisoned content from the cache. Any following messages are then redirected to the URL introduced by the attacker and allow that server to return a message that contains malicious code to the sender.

To protect against these HTTP response header injection attacks, administrators must create an allowed list of valid host names for each active security zone. The Host Header URLs from incoming request messages can then be validated against this list.

After an allowed list is established, the WebFOCUS Server accepts only incoming HTTP Request Messages that contain a URL that appears on this list and returns an error message stating that the resource did not process correctly for all other messages.

Administrators can define a list of allowed host names for their organization in the Allowed host names field of the Authentication Options dialog box. By default, this field contains an asterisk (*) wild card, which accepts incoming HTTP Request messages directed to all host name URLs. We recommend that you accept this option only if you have incorporated an independent application that validates host names in HTTP Request Headers before they are accepted by the WebFOCUS Reporting Server.

Procedure: How to Configure the Allowed Host Names List

To restrict the acceptance of incoming HTTP Request messages within a security zone to those that contain the URL of an existing virtual host on the WebFOCUS Server, administrators must replace the asterisk (*) wildcard character in the Allowed host names field of the Authentication options dialog box with a comma-separated allowed list of the URLs of virtual hosts, web sites, or applications, located on the WebFOCUS Server. URLs in the host header field of incoming HTTP Request messages must match a URL in this list to be accepted.

  1. In the Administration Console, select the Security tab.
  2. On the Security tab, expand the folder for the Security Zone that contains the Allowed Host Names list you wish to configure, and select the Authentication page node.
  3. In the Actions section of the Authentication page, select Options to open the Authentication Options dialog box.
  4. Enter the URL for each virtual host that is defined on the WebFOCUS Reporting Server and is allowed to process incoming HTTP Request messages in the Allowed host header field.
    • You can enter a fully qualified URL to represent a single host name. For example, www.samplehost.com. Matches against fully qualified URLs must be exact and are case-sensitive.
    • You can also use a period (.) as a wildcard to represent a range of host names. For example, the wildcard in the .ibi_apps.com URL would match www.ibi_apps.com, www.server1.ibi_apps.com, and any other URL that contains characters preceding ibi_apps.com.
    • If you must list multiple URLs in this field, separate each URL with a comma.
  5. Delete any URLs that are outdated or no longer allowed.
  6. Select OK to save the list.
  7. On the Authentication page, in the Security Zones section, select Save.
  8. When you receive a message stating that the web security configuration data was saved successfully, select OK.
  9. When you receive a message advising you to reload the web application in order for these changes to take effect, select OK.
  10. Sign out of your current session.
  11. Stop and restart the WebFOCUS Server.
  12. Sign in again as an administrator and test the new configuration.

Configuring Cross-Origin Settings

External applications can take advantage of WebFOCUS business intelligence by embedding WebFOCUS content and resources into their webpages. For example, an external application designed to provide customer service can embed portals designed and built within WebFOCUS that add reporting, charting, and analytic resources to the customer service metrics or account service history information they display.

However, to protect WebFOCUS from requests to embed its resources or content from unknown and unauthorized external applications, WebFOCUS does not allow embedding, by default. By selecting the Allow Embedding check box in the Cross-Origin Settings dialog box, an administrator can override this default configuration, and allow WebFOCUS to accept requests to embed portals, pages, or other resources into a frame or iframe within the webpage of a trusted external application.

External applications can also take advantage of WebFOCUS business intelligence by making embedded WebFOCUS content and resources interactive. Asynchronous Ajax requests issued from the browsers of users of the embedded application retrieve or update WebFOCUS resources and content dynamically, keeping information current and allowing for user interaction with embedded content.

Cross-origin resource sharing (CORS) allows a web page to request restricted resources from another domain outside of the domain from which the first resource was served. Using a cross-origin resource sharing policy configuration, a web page may be permitted to embed cross-origin images, stylesheets, scripts, iframes, and videos from separate domains, but forbid more sensitive cross-domain requests, such as Ajax requests. Because it allows a resource to limit cross-origin requests to a specific set of domains and messages, the CORS standard defines a way in which a browser and server can interact to determine whether or not it is safe to allow a cross-origin request. It allows for more freedom and functionality than purely same-origin requests, but is more secure than simply allowing all cross-origin requests. It is a recommended standard of the W3C consortium. For more information see, https://en.wikipedia.org/wiki/cross-origin_resource_sharing and the Cross-Origin Resource Sharing Recommendation from the W3C consortium http://www.w3.org/TR/cors/.

The Cross-Origin Settings dialog box activates the use of Embedding and Cross-Origin Resource sharing within WebFOCUS, as shown in the following image. The Allow Embedding check box supports the basic request to embed content within a frame or iframe of an external webpage. The Allow Cross-Origin Resources Sharing (CORS) check box supports the use of Ajax cross-origin sharing requests.

The Cross-Origin Settings dialog box with the default settings for all fields and check boxes.

Note: Even though the Allow Embedding and Allow Cross-Origin Resources Sharing (CORS) check boxes appear together in the Cross-Origin Settings dialog box and work together to support the full requirements of Embedded BI Applications, these two settings are not dependent on each other. For example, an installation of WebFOCUS can be configured to support an external application that uses cross-origin resource sharing but does not require the use of embedded WebFOCUS content in a frame or iframe. Another installation of WebFOCUS could be configured to support an simple application that embeds a portal in a frame or iframe, but does not support cross-origin Ajax requests.

Defining Origins

In the Cross-Origin Resource Sharing standard, an origin is defined by the scheme, host, and port of a URL. The Scheme identifies the protocol of the host it represents, typically http:\\ or https:\\. The Host identifies the registered name (including but not limited to a hostname), or IP address of the host. The Port identifies the endpoint of communications for the host.

As long as these three components are effectively the same, the URL defines the same origin. For example, both of the following resources have the same origin, even though the host component of the second resource URL contains additional path information:

  • http://example.com/
  • http://example.com/path/file/

However, in the following examples, each of the resources has a different origin from the others:

  • http://example.com/
  • http://example.com/8080/
  • http://www.example.com/
  • https://example.com:80/
  • https://example.com/
  • http://example.org/
  • http://ietf.org/

In each case, at least one of the scheme, host, and port components differs from others in the list. For more information, see https://tools.ietf.org/html/rfc6454.

Allowing Embedding

The Allow Embedding check box determines whether or not requests to embed content within a frame or iframe on the webpage of an external application are allowed. When this check box is selected, the Allowed Origins field beneath it defines the range of applications that are allowed to embed WebFOCUS content.

TIBCO WebFOCUS either allows or prevents embedding by assigning specific values to the X-Frame-Options ALLOW-FROM header or to the Content-Security-Policy header of the message it sends in response to a request for embedded content. The specific response header used depends upon the type of browser requesting the resource. The values in the Allow Embedding check box and the Allowed Origins field associated with it are assigned to these response headers.

By default, the Allow Embedding check box is cleared, and WebFOCUS assigns the SAMEORIGIN value to the response header, which will prevent WebFOCUS from embedding resources within a frame or iframe in an external application.

The Allowed Origins field contains the asterisk wild card character (*), by default. When the Allow Embedding check box is selected, and the Allowed Origins field contains the asterisk wild card character (*), the ALLOW-FROM or Content-Security-Policy header is excluded from the response message, allowing its content to be embedded in all third party applications.

To limit the range of external applications that are allowed to embed TIBCO WebFOCUS resources, an administrator must replace the asterisk (*) wild card character in the Allowed Origins field with a comma-separated whitelist of URLs that host the specific origins that TIBCO WebFOCUS supports. Every URL in the whitelist must contain the scheme, hostname, and port of the external host. The port should be excluded if the URL uses the default port for the protocol it uses in the scheme, port 80 for URLs using the http protocol or port 443 for URLs using the https protocol.

When the Allow Embedding check box is selected, and the Allowed Origins field contains a specific URL or a comma-delimited whitelist of URLs, TIBCO WebFOCUS assigns the whitelist of Allowed Origins, depending on the type of browser that issued the request, to the response header. This setting allows only the specific hosts identified in that whitelist to embed TIBCO WebFOCUS content.

Permission to allow embedding varies by security zone. This feature ensures that embedding can be limited to those security zones that support requests from external applications, and prohibited in those security zones that do not.

The Allow Embedding setting only supports the placement of webpages within a frame or iframe. The separate Allow Cross-Origin Resources Sharing (CORS) request supports the request to retrieve or update resources or content within a webpage. For more information see, Allowing Cross-Origin Resource Sharing.

For more information about Embedded BI Applications, see the TIBCO WebFOCUS® Embedded Business Intelligence User's Guide.

Procedure: How to Allow Embedding for a Security Zone

  1. In the Administration Console, click the Security tab.
  2. On the Security tab, under the Security Zones folder, click the Authentication node for the zone that will support embedded BI applications.

    Most installations assign this configuration to the Default Security zone, but they may also use the Alternate Security zone if they do not use the Default Security zone to support embedded BI applications.

  3. On the Authentication page, click Cross-Origin Settings.
  4. In the Cross-Origin Settings dialog box, select the Allow Embedding check box, as shown in the following image.
    The Allow Embedding check-box in the Cross-Origin Settings dialog box.
  5. To allow HTTP requests and responses from all applications, accept the asterisk (*) wild card character in the Allowed Origins field under the Allow Embedding check box.
  6. To allow HTTP requests and responses from specific applications, type the URL for each allowed application in the Allowed Origins field under the Allow Embedding check box.

    When typing URLs in this field, keep the following requirements in mind:

    • You must include the scheme, meaning the term http: or https:, in each URL.
    • If you use URLs in the format http://hostname.domain.com or http://hostname to access websites within your network, you must include both URLs in the whitelist.
    • If you include multiple URLs in the whitelist, you must separate each one with a comma, as shown in the following image.
      The Allow Embedding check-box in the Cross-Origin Settings dialog box. with a whitelist of URLs in the Allowed Origins field.
    • Add a port number only to those URLs that do not use the default http or https port of 80 or 443, respectively. Port 80 identifies the port for all Hypertext Transfer Protocol HTTP services, and port 443 identifies the port for all HTTP secure services. Therefore, if the scheme of a URL is http and the port is 80, the port does not need to be included. Similarly if the scheme is https and the port is 443, the port does not need to be included.
  7. Click OK.

    To activate cross-origin resource sharing for external applications, see How to Allow Cross-Origin Resource Sharing for a Security Zone.

    For more information about the configuration of Embedded BI Applications, see the TIBCO WebFOCUS® Embedded Business Intelligence User's Guide.

Allowing Cross-Origin Resource Sharing

The Allow Cross-Origin Resources Sharing (CORS) check box determines whether or not TIBCO WebFOCUS allows cross-origin sharing requests for content or resources from external applications. When this check box is selected, the Allowed Origins field beneath it defines the range of applications that are allowed to deliver cross-origin sharing requests.

TIBCO WebFOCUS either allows or prevents cross-origin sharing by assigning specific values to the Access-Control-Allow-Origin header of the message it sends in response to Ajax messages requesting cross-origin sharing. The values in the Allow Cross-Origin Resources Sharing (CORS) check box and the Allowed Origins field associated with it define the values that are assigned to this response header.

By default, the Allow Cross-Origin Resources Sharing (CORS) check box is cleared, and TIBCO WebFOCUS responds to cross-origin sharing requests with an HTTP 403 error message, which prevents TIBCOWebFOCUS from sharing resources with an external application.

The Allowed Origins field contains the asterisk wild card character (*), by default. When the Allow Cross-Origin Resources Sharing (CORS) check box is selected, and the Allowed Origins field contains the asterisk wild card character (*), TIBCO WebFOCUS assigns the wild card character to the Access-Control-Allow-Origin response header allowing its resources to be available to all external applications.

To limit the range of external applications that are allowed to share TIBCO WebFOCUS resources, an administrator must replace the asterisk (*) wild card character in the Allowed Origins field with a comma-separated whitelist of URLs that host the specific origins that TIBCO WebFOCUS supports. Every URL in the whitelist must contain the scheme, hostname, and port of the external host. The port should be excluded if the URL uses the default port for the protocol it uses in the scheme, port 80 for URLs using the http protocol or port 443 for URLs using the https protocol.

When the Allow Cross-Origin Resources Sharing (CORS) check box is selected, and the Allowed Origins field contains a specific URL or a comma-delimited whitelist of URLs, TIBCO WebFOCUS assigns the whitelist of Allowed Origins to the Access-Control-Allow-Origin response header. This setting allows TIBCO WebFOCUS to share resources only with the specific hosts identified in that whitelist in response to Ajax request messages.

Once activated, the remaining features establish a standard set of protections over the use of cross-origin resources for those embedded applications supported by the security zone, as shown in the following image.

The Allow Cross-Origin Resource Sharing (CORS) section of the Cross-Origin Settings dialog box with CORS settings activated.

Settings in this dialog box incorporate all of the features that the cross-origin resource sharing specification will support, such as URLs, request methods, headers, and credentials. They also define the maximum time by which preflight requests must be completed.

Permission to allow cross-origin resource sharing varies by security zone. This feature ensures that cross-origin resource sharing can be limited to those security zones that support requests from external applications, and prohibited in those security zones that do not.

The Allow Cross-Origin Resources Sharing (CORS) check box only supports the use of cross-origin requests to retrieve or update resources or content within a webpage. The separate Allow Embedding request supports the request to embed content within a frame or iframe in an external application webpage. For more information see, Allowing Embedding.

For more information about Embedded BI Applications, see the TIBCO WebFOCUS® Embedded Business Intelligence User's Guide.

Procedure: How to Allow Cross-Origin Resource Sharing for a Security Zone

  1. In the Administration Console, click the Security tab.
  2. On the Security tab, under the Security Zones folder, click the Authentication node for the zone that supports embedded applications.

    Most installations assign this configuration to the Default Security zone, but they may also use the Alternate Security zone if they do not use the Default Security zone to support Embedded BI Applications.

  3. On the Authentication page, click Cross-Origin Settings.
  4. In the Cross-Origin Settings dialog box, select the Allow Cross-Origin Resources Sharing (CORS) check box.

    Settings in the dialog box become available, as shown in the following image.

    The Allow Cross-Origin Resource Sharing (CORS) section of the Cross-Origin Settings dialog box with CORS settings activated and no URLS assigned..
  5. Type the URL for each application that is allowed to issue cross-origin resource sharing requests to TIBCO WebFOCUS in the Allowed Origins field under the Allow Cross-Origin Resources Sharing (CORS) check box.

    When typing URLs in this field, keep the following requirements in mind:

    • You must include the scheme, that is, the term http: or https:, in each URL.
    • If you use URLs in the format http://hostname.domain.com or http://hostname to access websites within your network, you must include both URLs in the whitelist.
    • If you include multiple URLs in the whitelist, you must separate each one with a comma, as shown in the following image.
      The Allow Cross Origin Resource Sharing (CORS) check-box in the Cross-Origin Settings dialog box with a whitelist of URLs in the Allowed Origins field.
    • Add a port number only to those URLs that do not use the default http or https port of 80 or 443, respectively. Port 80 identifies the port for all Hypertext Transfer Protocol HTTP services and port 443 identifies the port for all HTTP secure services. Therefore, if the scheme of a URL is http and the port is 80, the port does not need to be included. Similarly if the scheme is https and the port is 443, the port does not need to be included.
  6. Accept the default values assigned to all of the remaining fields and check boxes.

    When your configuration is complete, the dialog box will resemble the following image.

    The Cross-Origin Settings dialog box with the default settings for all fields and check boxes.
  7. Click OK.

    For more information about the configuration of Embedded BI Applications, see the TIBCO WebFOCUS® Embedded Business Intelligence User's Guide.

Configuring HTTP Strict Transport Security (HSTS) Within a Security Zone

In this section:

How to:

The HTTP Strict Transport Security Settings link connects you to the HTTP Strict Transport Security Settings dialog box, where you can implement the use of an HSTS security policy for your selected Security Zone. This policy calls for the use of TLS (SSL) level security on all communications between browsers assigned to individual users and the Application Server. Therefore, it is relevant only to those organizations that have configured the use of TLS (SSL) security. For more information, see Configuring TIBCO WebFOCUS for SSL.

An HTTP Strict Transport Security (HSTS) policy is a security enhancement issued by a server that requires the use of the https protocol for all incoming requests. When this policy is in place, the server that hosts a website responds to the first request from a browser that does not use the https protocol by returning a message with a response header that contains the Strict-Transport-Security field. The presence of this field in the response header indicates that the server will not accept any further requests from that browser that do not arrive over an https connection.

The response header can also include a field identifying the time limit, typically one year, over which the policy will be enforced. Any subsequent requests from that browser that do not use this protocol will receive an error message in response.

When the browser receives a message with a response header that contains a Strict-Transport-Security field, it knows to use the https protocol when sending any future messages to the site. The browser also knows that any other site using the same name that does not require the use of this protocol is not legitimate, and it automatically redirects requests to the site that does require the use of the https protocol.

By imposing this policy within a Security Zone, you introduce this extra level of security to all communications between users in that zone and the Application Server. The policy ensures that all communications within that zone use the https protocol and are therefore encrypted and validated by a public key certificate. It also helps prevent requests from users in that zone from being inadvertently misdirected to an illegitimate site that does not require the https protocol.

A link to the HTTP Strict Transport Security Settings dialog box and its configuration appears on the Authentication page of the Administration Console Security tab. Because the policy only applies to the zone in which it is configured, you will need to establish this policy for each of the security zones in which it will apply. As a best practice, we recommend the use of the HSTS policy for all security zones in installations that have been configured to use TLS (SSL) security.

Understanding the HTTP Strict Transport Security Setting Dialog Box

The HTTP Strict Transport Security Settings dialog box enables the HSTS policy for a selected Security Zone. Additional settings define the length of time that the policy is enforced and whether or not the policy extends to messages directed to subdomains within the host server URL.

HTTP Strict Transport Security is not enabled, by default, for any security zone, therefore the features in this dialog box remain unavailable until you select the Enable HTTP Strict Transport Security (HSTS) check box.

The HTTP Strict Transport Security Settings dialog box, with the Enable HTTP Strict Transport Security (HSTS) check box cleared and unenabled.

When selected, the Enable HTTP Strict Transport Security (HSTS) check box activates the HSTS policy for the security zone selected in the left pane of the Security tab. When this check box is selected, the other features in the dialog box become available.

The Max Age (seconds) list contains the number of seconds for an entire year, by default. You can increase or decrease this value to conform to the standards of your organization.

The Apply HSTS policy to all the sub-domains check box is cleared, by default. However, we recommend that you select it in order to ensure that messages directed to all subdomains in the site hosting the Application Server are required to use the https protocol.

Procedure: How to Configure HSTS Security for a Security Zone

This configuration is relevant only if you have also configured the use of TLS (SSL) in internal communications. For more information, see Configuring TIBCO WebFOCUS for SSL.

  1. Sign in as an administrator, open the Administration Console, and select the Security tab.
  2. On the Security tab, under the Security Zones folder, select the Authentication node for the zone in which you will enable HSTS.

    If you have configured TIBCO WebFOCUS to use https, we recommend that you enable this feature for all security zones in use within your installation.

  3. On the Authentication page, select HTTP Strict Transport Security Settings to open the HTTP Strict Transport Security Settings dialog box.
  4. Select the Enable HTTP Strict Transport Security (HSTS) check box.
  5. Accept the default value of 31536000 in the Max Age (seconds) field to establish the use of HTTP Strict-Transport-Security for a full year.

    You can use the up or down arrows to the right of this field to increase or decrease the number of seconds in this value.

  6. Select the Apply HSTS policy to all the sub-domains check box to add the requirement that all requests to subdomains within the Application Server use the https protocol.
  7. Select OK to save your configuration.
  8. Save changes to the Security Zone as described in How to Save Changes to the Authentication Page.

Understanding the Request Matching Page

In this section:

The Request Matching page defines the range of authentic URLs and IP addresses for a Security Zone. The page contains two tabs, Request URL Pattern, and IP Address of Client/Last Proxy. These tabs identify the patterns of URLs and IP Addresses of trusted users. A pattern can be very general to include a wide range or URLs and IP Addresses, or it can be very precise to limit valid requests to a few URLs and IP Addresses. When configured for a Security Zone, settings on the Request Matching page tabs exclude all request messages except those that match the pattern of trusted URLs and IP Addresses. By excluding requests from untrusted locations, the Request Matching pages help prevent potentially malicious requests from compromising WebFOCUS operations.

Request URL patterns use the following Java Ant path patterns.

  • All elements in the URL pattern are separated with forward slashes.
  • A single question mark (?) represents a single character.
  • A single asterisk (*) represents a string of zero or more characters.
  • Two asterisks (**) represents zero or more directories in a path.

Do not make modifications to the settings on this page unless instructed to do so by a member of the Customer Support Team.

Understanding the URL Request Pattern Tab

The Request URL Pattern tab defines the range of URLs that can be accepted as authentic origins for user requests.

The default settings for this tab vary by Security Zone to reflect differences in the security restrictions required by each one. For example, the Mobile and Portlet Security Zones support users who work at remote sites or through a portlet. Their configurations therefore strictly limit the range of acceptable URLs to a few patterns, by default. In contrast, the Default and Alternate Security Zones support all users who work at sites within an organization and their default configurations impose few to no restrictions.

Understanding the IP Address of the Client/Last Proxy Tab

The IP address of the Client/Last Proxy tab defines the range of client and proxy site IP Addresses that can be accepted as authentic origins for user requests. A proxy site, or proxy server, is a server that acts as an intermediary in all messages exchanged between a user and an application server.

The default settings for this tab vary by zone to reflect differing security restrictions required by each zone. The Default, Mobile, and Portlet zones contain no values for this tab, and the Add, Edit, and Remove links are unavailable, effectively making the evaluation of the client or last proxy IP addresses irrelevant.

By contrast, the IP Address of the Alternate Security Zone contains three default patterns, 127.0.0.1, 0:0:0:0:0:0:0:1, and ::1. All of these patterns are representations of the LocalHost IP address in IPV4 and IPV6 respectively, limiting the Alternate Security Zone to requests issued from local users. The Add, Edit, Edit Setting and Remove links are also available in this zone. Any configuration of these features will affect only those users who are assigned to the Alternate Zone.

Importing and Exporting Security Zone Settings

How to:

The settings for each security zone are stored in four security configuration files, securitysettings.xml, securitysettings-mobile.xml, securitysettings-portlet, and securitysettings-zone.xml. Before you change the authentication method for a zone, use the Export link on any zone page to save a backup zip file of the security zone configuration. If you need to restore a previous configuration of security zone settings, use the Import link to capture settings from that configuration and restore them to the security configuration files on the server.

Procedure: How to Export Security Configuration Files

The Export link creates a zip copy of the four security configuration files from the server and saves them in a designated network location. Use this operation to backup existing security configuration settings before updating them.

  1. On the Authentication or Request Matching page of a Security Zone, in the Actions section, click Export.
  2. When you receive a message asking you to open the zip file, click Open.
  3. From the WinZip dialog box menu bar, click File, and then click Save As.
  4. Accept the default name for the file, or type a new name for it.
  5. Navigate to the location for the new file, and then click Save.
  6. From the WinZip dialog box menu bar, click File, and then click Exit.

Procedure: How to Import Security Configuration File Settings

The Import feature enables you to copy and paste the text of previous versions of the security configuration files into the four security files on the WebFOCUS server. Use this operation whenever you need to restore previously established security configuration settings.

  1. On the Authentication or Request Matching page of a Security Zone, in the Actions section, click Import.
  2. In the Import the Web Security Configuration Data dialog box, click the tab that represents the configuration file for the zone that must contain this new configuration data, securitysettings.xml, securitysettings-mobile.xml, securitysettings-portlet.xml, or securitysettings-zone.xml.
  3. Copy the configuration text from your independent source file.
  4. In the Please copy the web security configuration data from your local hard files and paste here box, paste the text from that source file.
  5. Click Apply.
  6. When the confirmation dialog box opens, click OK to complete the import.
  7. If you receive a message stating that the import failed to parse the input web security configuration data, click OK, adjust the text as necessary, and repeat steps 5 and 6.