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:
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:
This section contains the following topics:
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.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.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.
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:
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.
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."
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.
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:
Section 6.2.1, "Properties That Configure Security Settings"
Section 6.2.4, "URLs and the Web Server (Delivery System Only)"
Section 6.2.5, "WebCenter Sites Forms and Pages (Delivery System Only)"
This section describes how to configure the properties in the futuretense.ini file that implement various kinds of security.
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.
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)."
Be sure that the default user accounts were made secure after WebCenter Sites was installed on 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.
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.
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.
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
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
.
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:
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.CatalogManage
r 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.
Verify that the sample site users do not exist on the management or delivery systems.
Verify that you cannot log in with ContentServer/password
using a CatalogManager URL:
http://<server>:<port>/<context>/CatalogManager?ftcmd=login&username=ContentServer&password=password
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
Verify that you cannot log in to the application server as the default administrator user.
Verify that you cannot log in to the database as the default administrator user.
Verify that you cannot log in to the web server as the default administrator user.