6 Setting Up External Security

Determining what your security protocols should be and then implementing them is an important part of a WebCenter Sites administrator's duties. You and the site developers must discuss and determine how security will be configured on both the management and the delivery systems before they start coding templates and designing asset types.

This chapter contains the following sections:

6.1 Overview

Before developers begin designing the online site or contemplating changes to the user interface on the management system, you must determine and implement your security protocols. The decisions you make about security configuration affects the way that you code and implement your online site.

At regular intervals, you should review your systems to determine whether they are working as they should. Figure 6-1 shows an example of a secure WebCenter Sites system:

Figure 6-1 WebCenter Sites System

Description of Figure 6-1 follows
Description of ''Figure 6-1 WebCenter Sites System''

This section contains the following topics:

6.1.1 ACLs and Security

As mentioned in Chapter 4, "Working with ACLs and Roles," ACLs (access control lists) serve as the foundation of the security and user management model in your WebCenter Sites system. ACLs are sets of permissions that restrict access to both database tables and WebCenter Sites pages.

ACL restrictions are enforced only when the cc.security and the security.checkpagelets properties in the futuretense.ini file are set to true. These properties are set to true by default. If you need to disable security for any reason, open the Property Editor and set the cc.security property to false. However, Oracle recommends that you keep this property set to true on all systems to ensure that site development is designed to work with security enabled.

When planning security measures for your system, examine the list of default ACLs (described in Chapter 31, "System Defaults"), and determine whether you need additional ACLs. You might need to create an ACL with a different combination of permissions than any of the system ACLs provide if your developers plan to create new tables or to make additions to the user interface.

Note:

Under no circumstances should you modify a system default ACL or modify the ACLs assigned to a WebCenter Sites system table or a Sites content application table.

6.1.2 DefaultReader, secure.CatalogManager, and secure.TreeManager

WebCenter Sites and the WebCenter Sites content applications are delivered with several default user accounts, one of which is named DefaultReader. This account is assigned to all unauthorized site visitors (because anyone who visits a site hosted by WebCenter Sites must have a WebCenter Sites user identity).

By default, the DefaultReader user account has the following ACLs: Browser and Visitor. Visitor enables the tracking of visitors for demographic purposes. Security issues arise because many of the database tables also have the Browser ACL assigned to them, and various Engage tables are assigned the Visitor ACL. Therefore, anyone using the DefaultReader account can examine information in the tables (although they cannot write to the tables as this user). To prevent someone from using the DefaultReader user account to view tables in your WebCenter Sites database, set the following properties in the futuretense.ini file to true:

  • secure.CatalogManager

  • secure.TreeManager

When these properties are set to true, the DefaultReader user cannot access the CatalogManager and TreeManager servlets—not even for read-only data.

Note:

More information about Oracle WebCenter Sites: Engage ACLs (Visitor and VisitorAdmin) is available in Chapter 31, "System Defaults." See Table 31-3, "System ACLs and Their Descriptions" for permissions that are associated with each ACL and Table 31-4, "Default Users and Their ACLs" for descriptions of the ACLs.

6.1.3 BlobServer and Security

When you want to implement security for your blobs you must enable the security feature for the BlobServer servlet. You do this by setting the bs.security parameter in the futuretense.ini file to true.

When bs.security=true, BlobServer refuses to serve a blob unless the URL for the blob contains evidence that the person requesting it has been authenticated as a valid user. What evidence? A value in the URL from the csblobid parameter whose value matches a session variable named csblobid. Therefore, when BlobServer security is enabled, your developers must code links to blobs differently than usual.

For information about how those links should be coded, see the Oracle Fusion Middleware WebCenter Sites Developer's Guide.

6.1.4 Security Goals

Typically, you have a different set of security goals for each of your WebCenter Sites systems: the development, management, and delivery systems.

This section contains the following topics:

6.1.4.1 Security Goals for the Development System

Even though development systems are typically behind firewalls, you should implement the same security configuration on the development system that will be in place on the system the developers are designing for (management or delivery). Why? To be sure that the code will work properly on the target system, because the same conditions exist on both systems:

  • When you plan to use BlobServer security on the delivery system, templates that create URLs for blobs must be coded differently. Therefore, you must enable BlobServer security on the development system as well.

  • If your online site will require that visitors identify themselves, you must have the same security configuration in place on the development system that you will use on the delivery system.

6.1.4.2 Security Goals for the Management System

Security on the management system encompasses two main concepts:

  • Ensuring that only valid WebCenter Sites users can access the system (described in this chapter).

  • Ensuring that those valid users can access only the functions that are appropriate for them. For information, see Chapter 4, "Working with ACLs and Roles."

6.1.4.3 Security Goals for the Delivery System

The precautions that you take on the delivery system are more stringent by nature because when you deliver a site to the public, you must ensure that while visitors can access the content on your site, hackers cannot access areas that you do not want made public.

When you configure your delivery system, you disable the WebCenter Sites user interfaces to prevent anyone from adding assets or code through the interfaces or with any of the developer tools. Additionally, you restrict access to some of the WebCenter Sites servlets.

6.2 Implementing Security

This section describes the steps you must take to configure the security measures you have decided to implement: setting properties, changing passwords for default user accounts, using SSL for systems accessible outside your company's network, mapping URLs for specific WebCenter Sites servlets, and disabling certain parts of the applications on the delivery system.

Each section states which steps should be performed on which system or systems.

This section contains the following topics:

6.2.1 Properties That Configure Security Settings

This section describes how to configure the properties in the futuretense.ini file that implement various kinds of security.

For All Systems

Use the Property Editor to open the futuretense.ini file and verify that the following properties are set to true:

  • cc.security

  • security.checkpagelets

  • secure.CatalogManager

  • secure.TreeManager

If you plan to use BlobServer security, set the following property to true:

bs.security

To ensure that the session timeout value is appropriate for each system, set the following property, as well:

cs.timeout

On the development and management systems, set the timeout value for as long as you think that you safely can. On the delivery system, set the timeout value for as short a time as you can without frustrating your visitors.

For the Delivery System

In addition to the properties described in the preceding section, there is one more property to specify for the delivery system: cs.wrapper.

Wrappers are the HTML files located in the futuretense_cs directory on the web server. Also included in that directory is a subdirectory named Dev, which you should remove from your delivery system.

However, if you decide to remove the entire futuretense_cs directory from the web server on the delivery system, you must set the cs.wrapper property to false.

For more information, see Section 6.2.5, "WebCenter Sites Forms and Pages (Delivery System Only)."

6.2.2 Users and Passwords

Be sure that the default user accounts were made secure after WebCenter Sites was installed on all systems.

For All Systems

Complete the following steps on all systems—development, management, and delivery:

  • Change the default password for the fwadmin user account (User node under User Access Management in the Admin tab in the administrator's interface).

  • If the WebCenter Sites user that was created during the installation is named ContentServer, verify that its password is not the default password (password). If the password used is the default password, change it (User node under User Access Management in the Admin tab in the administrator's interface).

  • Change the default administrator username/password for your application server.

  • Change the default administrator username/password for your web server.

  • If you have the sample sites installed, a mirror user was created for the Mirror to Server publishing method (name: mirroruser; password: mirroruser). Change the password for this user.

  • For any user accounts that have the SiteGod ACL, change the password frequently (User node under User Access Management in the Admin tab in the administrator's interface). Handle any user account that has the SiteGod ACL as you would the UNIX root user.

    Note:

    Do not change the default password for the DefaultReader user.

For the Management and Delivery Systems

If any of the sample sites except AviSports or FirstSiteII were installed on either the management or delivery systems, delete all the sample users including editor, but do not delete the xceleditor ACL and do not delete the fwadmin user. Additionally, change the password for the mirroruser user.

For the Delivery System

Do not assign the xceleditor ACL to any user on the delivery system other than the system administrator of that system. This ACL allows access to the WebCenter Sites content applications if they are installed on that delivery system.

6.2.3 SSL and Digital Certification

For any system accessible outside your company's network or containing proprietary data, such as a management system open to remote employees, it is recommended to use SSL to establish a secure, encrypted connection.

You must use a digital certificate approved by a trusted authority rather than a self-signed certificate. Using a self-signed certificate can have the following consequences:

  • Internal calls to the system made through Java may fail.

  • Some features of the user interface may not function correctly, for example, the left-hand navigation tree or publishing.

6.2.4 URLs and the Web Server (Delivery System Only)

On the web server of the delivery system, be sure to give access to the following WebCenter Sites servlets only. How? By mapping only their URLs to the application server:

  • ContentServer

  • BlobServer

  • Satellite

  • CookieServer

Do not map URLs to the application server for any of the other WebCenter Sites servlets. Instead, map the URLs for the following servlets to an error page such as the "404 Not Found" page:

  • HelloCS

  • CatalogManager

  • TreeManager

  • DebugServer

  • CacheServer

  • Inventory

6.2.5 WebCenter Sites Forms and Pages (Delivery System Only)

On the delivery system, be sure to disable or completely remove the following pieces of the WebCenter Sites applications:

  • Remove the futuretense_cs/Dev directory from the web server. This directory holds forms that are useful for developers, which means that you do not want them on your delivery system.

    Note:

    Do not remove this directory from the application server. Remove it from the web server only.

    You can optionally remove the entire futuretense_cs directory from the web server. (Do not remove it from the application server.) If you do, be sure to set the cs.wrapper property in the futuretense.ini file to false (the wrappers are the HTML files from that folder). If you forget, visitors on the site will see "404 Page Not Found" rather than some of the system error messages.

  • Go to SiteCatalog/OpenMarket/Xcelerate/UIFramework and rename all of the pages. At the very least, rename LoginPage and LoginPost.

6.3 Testing Security

After you have implemented your security measures, test your systems.

Security Tests for All Systems

Complete the following steps on your development, management, and delivery systems:

  1. Try to log in to the database with Sites Explorer using the default user accounts:

    • DefaultReader

      If you can log in using SomeReader as the password, the secure.CatalogManager and secure.TreeManager properties are set to false. Change them to true.

    • ContentServer

      If you can log in using password as the password, change the password immediately.

    • editor

      If you can log in using xceleditor as the password, change the password immediately.

    • fwadmin

      If you can log in using xceladmin as the password, change the password immediately.

  2. Verify that the sample site users do not exist on the management or delivery systems.

  3. Verify that you cannot log in with ContentServer/password using a CatalogManager URL:

    http://<server>:<port>/<context>/CatalogManager?ftcmd=login&username=ContentServer&password=password

  4. Verify that you cannot flush the entire cache as ContentServer/password using a CacheServer URL:

    http://<server>:<port>/<context>/CacheServer?all=true&authusername=ContentServer&authpassword=password

  5. Verify that you cannot log in to the application server as the default administrator user.

  6. Verify that you cannot log in to the database as the default administrator user.

  7. Verify that you cannot log in to the web server as the default administrator user.