| Oracle® Fusion Middleware Enterprise Deployment Guide for Oracle WebCenter Interaction 10g Release 4 (10.3.3.0.0) Part Number E26810-01 |
|
|
View PDF |
| Oracle® Fusion Middleware Enterprise Deployment Guide for Oracle WebCenter Interaction 10g Release 4 (10.3.3.0.0) Part Number E26810-01 |
|
|
View PDF |
This chapter summarizes security concerns for Oracle WebCenter Interaction deployments. While this chapter provides a summary of security needs, it is not intended to replace the services of a qualified security professional. The purpose of this chapter is assist in developing a security plan and should not be considered a replacement for the services of qualified security professionals. Oracle does not advocate the use of any specific security configuration. Oracle does provide professional consulting services to assist in securing an Oracle WebCenter deployment. To engage Oracle professional services, contact your Oracle representative.
This chapter is divided into the following sections:
Determining Your Security Needs describes best practices for determining the security needs of your Oracle WebCenter deployment.
Security Architecture, provides an overview of the Oracle WebCenter component security architecture, including intra-component communication, firewalls, and the DMZ.
Ensuring the Security of Your Production Environment provides high-level descriptions of the security measures that can be employed to secure your Oracle WebCenter environment.
Configuring SSL, provides an overview of SSL in the Oracle WebCenter deployment, including how and where CA certificates should be imported into the various Oracle WebCenter services.
This section describes best practices for determining the security needs of your Oracle WebCenter deployment. It is divided into the following sections:
To better understand your security needs, ask yourself the following questions:
Which resources am I protecting?
Many resources in the production environment can be protected, including information in databases accessed by Oracle WebCenter Interaction and the availability, performance, applications, and the integrity of the website. Consider the resources you want to protect when deciding the level of security you must provide.
From whom am I protecting the resources?
For most websites, resources must be protected from everyone on the Internet. But should the website be protected from the employees on the intranet in your enterprise? Should your employees have access to all resources within the Oracle WebCenter environment? Should the system administrators have access to all Oracle WebCenter resources? Should the system administrators be able to access all data? You might consider giving access to highly confidential data or strategic resources to only a few well trusted system administrators. Perhaps it would be best to allow no system administrators access to the data or resources.
What will happen if the protections on strategic resources fail?
In some cases, a fault in your security scheme is easily detected and considered nothing more than an inconvenience. In other cases, a fault might cause great damage to companies or individual clients that use the website. Understanding the security ramifications of each resource will help you protect it properly.
Whether you deploy Oracle WebCenter on the Internet or on an intranet, it is a good idea to hire an independent security expert to go over your security plan and procedures, audit your installed systems, and recommend improvements. Oracle partners offer services and products that can help you to secure a Oracle WebCenter production environment. For details, visit the Oracle Support site at http://www.oracle.com/support/index.html.
For the latest information about securing web servers, Oracle recommends the "Security Practices & Evaluations" information available from the CERT™ Coordination Center operated by Carnegie Mellon University.
Report possible security issues in Oracle WebCenter products in the following ways by contacting Oracle technical support.
This section describes Oracle WebCenter component architecture from a network security perspective. This includes how various components communicate with each other and which components need to be exposed to the end consumer.
With the exception of the database and Search, all requests from the Oracle WebCenter Interaction portal component are made using HTTP 1.1. This provides the following security advantages:
There are third party tools to help monitor and audit HTTP 1.1 traffic.
Each component web service uses a single, configurable port number, which eases firewall configuration.
The Oracle WebCenter Interaction portal component implements the full range of HTTP security, including SSL/TLS certificates and basic authentication.
Single Sign-On (SSO) third party products that are designed to protect HTTP traffic can be used to protect web services residing in the internal network. For details on SSO and Oracle WebCenter, see Authentication and SSO
Communication between the Oracle WebCenter components can be further secured by:
Using a separate network or subnet for the Oracle WebCenter components and the DB.
Using technologies such as IPSec, VPN, or SSL.
A basic security architecture that limits external exposure to Oracle WebCenter products and other back-end systems is illustrated below.
In this configuration, only the Oracle WebCenter Interaction portal component and Image Service are placed within the DMZ. The Oracle WebCenter Interaction portal component and Image Service should be the only Oracle WebCenter components installed in the DMZ. When the portal is separate from other Oracle WebCenter components, persistent data in the search and database components and back-end tasks in the automation service are isolated from the external network.
The portal gateways requests to all other Oracle WebCenter components and back-end services, communicating with HTTP 1.1 across the firewall and into the internal network. The server housing the Oracle WebCenter Interaction portal should be hardened by a security professional, as it receives direct user requests. All communication should be SSL-encrypted.
To avoid traffic across the firewall between non-portal Oracle WebCenter components and the Image Service, another Image Service can be placed within the internal network.
Note:
This is one potential network topology. For topologies involving software and hardware load balancing, see Chapter 8, "Load Balancing."
This section provides high-level descriptions of the security measures that can be employed to secure your Oracle WebCenter environment. It is divided into the following sections:
An Oracle WebCenter production environment is only as secure as the security of the machines on which it is running. It is important that you secure the physical machine, the operating system, and all other software that is installed on the host machine. The following are suggestions for securing your Oracle WebCenter Interaction host in a production environment. Also check with the manufacturer of the machine and operating system for recommended security measures.
Table 5-1 Securing Oracle WebCenter Hosts
| Security Action | Description |
|---|---|
|
Physically secure the hardware. |
Keep your hardware in a secured area to prevent unauthorized operating system users from tampering with the deployment machine ore its network connections. |
|
Secure networking services that the operating system provides |
Have an expert review network services such as e-mail programs or directory services to ensure that a malicious attacker cannot access the operating system or system-level commands. The way you do this depends on the operating system you use. Sharing a file system with other machines in the enterprise network imposes risks of a remote attack on the file system. Be certain that the remote machines and the network are secure before sharing the file systems from the machine that hosts Oracle WebCenter components. |
|
Use a file system that can prevent unauthorized access. |
Make sure the file system on each Oracle WebCenter component host can prevent unauthorized access to protected resources. For example, on a Windows computer, use only NTFS. |
|
Set file access permissions for data stored on disk. |
Set operating system file access permissions to restrict access to data stored on disk. This data includes, but is not limited to, the following:
For example, operating systems such as Unix and Linux provide utilities such as umask and chmod to set the file access permissions. At a minimum, consider using "umask 066", which denies read and write permissions to Group and Others. |
|
Set file access permissions for data stored in the portal database. |
Set operating system file access permissions to restrict access to data stored in the portal database. |
|
Safeguard passwords. |
The passwords for user accounts on production machines should be difficult to guess and should be guarded carefully. Set a policy to expire passwords periodically. Never code passwords in client applications. |
|
Do not develop on a production machine. |
Develop first on a development machine and then move code to the production machine when it is completed and tested. This process prevents bugs in the development environment from affecting the security of the production environment. |
|
Do not install development and sample software on a production machine. |
Do not install development tools on production machines. Keeping development tools off the production machine reduces the leverage intruders have should they get partial access to an Oracle WebCenter production machine. Do not install the Oracle WebCenter sample applications on production machines. |
|
Enable security auditing. |
Configure security auditing to enable monitoring of sensitive portal functions using the Audit Manager function. |
|
Consider using additional software to secure your operating system. |
Most operating system can run additional software to secure a production environment. For example, an Intrusion Detection System (IDS) can detect attempts to modify the production environment. Refer to the vendor of your operating system for information about available software. |
|
Apply operation-system service packs and security patches. |
Refer to the vendor of your operating system for a list of recommended service packs and security-related patches. |
|
Apply the latest Oracle WebCenter maintenance packs and implement the latest security advisories. |
If you are responsible for security related issues on your site, review the alerts and patches available on the Oracle Support site at In addition, you are advised to apply each maintenance pack as it is released. Maintenance packs are a roll-up of all bug fixes for each version of the product. |
Most web applications use a database to store their data. Common databases used with Oracle WebCenter are Oracle 10G and Microsoft SQL Server. The databases frequently hold sensitive data. When creating your web application you must consider what data is going to be in the database and how secure you need to make that data. You also need to understand the security mechanisms provided by the manufacturer of the database and decide whether they are sufficient for your needs. If the mechanisms are not sufficient, you can use other security techniques to improve the security of the database, such as encrypting sensitive data before writing it to the database. For example, leave all customer data in the database in plain text except for the encrypted credit card information.
Configuring Oracle WebCenter Interaction to use SSL is a relatively complex procedure that requires knowledge of SSL and CA certificates. This section provides an overview of the procedure. For more details, see the Oracle Fusion Middleware Administrator's Guide for Oracle WebCenter Interaction.
In the general case, the Oracle WebCenter Interaction portal Image Service would be secured with SSL, while another, unsecured Image Service would reside in the internal network for other Oracle WebCenter components. In this case Oracle WebCenter applications such as Oracle WebCenter Collaboration would use the unsecured Image Service and would only need to be configured for SSL communication with the portal.
The following sections explain how to configure the various Oracle WebCenter components for SSL:
After Oracle WebCenter components are installed, the security mode for the portal can be set. The security mode specifies how SSL is incorporated into your Oracle WebCenter deployment. Security mode options are described in the following table:
| Security Mode | Description |
|---|---|
|
0 |
Portal pages remain in whatever security mode—http or https—that the user initially uses to access the portal. For example, if a user accesses the portal via http, all the portal pages will remain http; if a user accesses the portal via https, all the portal pages will remain https. This is the default setting. Note: This mode is not recommended for production deployments or deployments that are exposed to the external network. |
|
1 |
Certain portal pages are always secured via SSL and other pages are not. For example, the login page might always be secured but a directory browsing page might not. The page types that are secured are configurable. Note: This mode is not generally recommended. |
|
2 |
All portal pages are always secured via SSL. Use this mode if there is no SSL accelerator. In this mode, the Web server should provide an SSL endpoint. Note: Configuring the SSL endpoint directly on a Tomcat application server is not recommended. A Web server should be used in front of the application server, and the SSL certificate should be installed on the Web server. |
|
3 |
The portal uses an SSL accelerator. This is the most common configuration for production deployments. As with Security Mode 2, users are not connecting to the application server directly, so the front-end application server and the channel between the accelerator and the application sever must be secured. |
For detailed information on configuring these settings, see the Oracle Fusion Middleware Administrator's Guide for Oracle WebCenter Interaction.
Use the following steps to configure Oracle WebCenter for SSL:
Configure SSL on Web servers or SSL accelerators that front-end the Oracle WebCenter Interaction portal and Image Service components. Refer to your Web server or SSL accelerator documentation for instructions on configuring SSL and creating, signing, and installing an SSL certificate.
Configure the Portal component:
Open PT_HOME/settings/config/portalconfig.xml.
Ensure that HTTPSecurePort and HTTPPort are set to the ports you want to use.
Change ApplicationURL0 from * to http://host_name:port/portal/server.pt
Note:
The port number is not necessary for .NET deployments.
Change SecureApplicationURL0 from * to https://host_name:port/portal/server.pt
Note:
The port number is not necessary for .NET deployments.
If multiple URL mappings are configured, ensure that these entries are updated as in Steps c and d. Refer to the comments in the configuration file for more information on URL mapping.
Change SecurityMode from 0 to 1, 2, or 3.
Change ImageServerSecureBaseURL from http to https. Ensure that the Image Service port is correct.
If the Image Service is secured with SSL, set ImageServerConnectionURL to the secure URL. The CA certificate used by the Image Service must be imported into the Portal application server. For details, see Importing CA Certificates.
If any portlets or remote servers use JSControls or Adaptive Portlets, the image service CA certificate must be imported into their runtimes as well. The JSControls libraries are embedded in server and IDK products, but are identified by XML stored on the Image Service.
If any remote server — including portlet servers, authentication sources, profile sources, or content services — is secured with SSL, import the remote server CA certificate into the Portal application server. For details, see Importing CA Certificates.
Configure Oracle WebCenter Collaboration to use the SSL-secured Portal and Image Service. For details, see Configuring Oracle WebCenter Applications to Use a Secure Portal or Image Service.
For each application server that makes requests to an SSL-secured service, the CA certificate from the secured service must be imported. The following two sections detail the process for importing CA certificates into a Java Application Server or IIS and .NET.
For Java application servers the CA certificate is imported into the cacerts keystore.
To import the CA certificate:
On the computer that makes requests to an SSL secured service, open a command prompt.
Copy the CA certificate to this computer.
Note:
The CA certificate is in the CA of the secured service. Save the .der encoded certificate as a .cer file.
Import the certificate using keytool. For example:
keytool -v -import -trustcacerts -alias CA_alias -file CA_certificate_path -keystore CA_keystore_path
where
CA_alias is the alias for the CA. For example, verisign or the server hostname.
CA_certificate_path is the path and filename of the .cer file to be imported.
CA_keystore_path is the path to the cacerts keystore. The cacerts keystore is typically located under the home of the JVM being run by the application server, JVM_HOME/lib/security/cacerts.
When prompted, enter the password for the cacerts keystore. The default password is changeme.
For IIS and .NET, the CA certificate is imported into the MMC.
On the computer that makes requests to an SSL secured service, open a command prompt.
Copy the CA certificate to this computer.
Note:
The CA certificate is in the CA of the secured service. Save the .der encoded certificate as a .cer file.
Run MMC from the command line,
> mmc
Click Console > Add/Remove Snap-in.
Click Add.
Click Certificates.
Click Computer Account and then click Next.
Click local computer and then click Finish.
Close the Add Standalone Snap-in dialog box.
Close the Add/Remove Snap-in dialog box by clicking OK.
In the MMC tree, expand to Console Root > Certificates > Trusted Root Certificate Authorities > Certificates.
Right click Certificates and select All Tasks > Import. Click Next.
Select the CA certificate to import. Click Next.
Choose to place all certificates in the Trusted Root Certification Authorities store.
Click Next and then click Finish.
Restart IIS.
This section describes how to configure Oracle WebCenter Collaboration and Oracle WebCenter BPM Suite to use a secure Portal or Image Service.
Oracle WebCenter Collaboration does not require any changes to function in security modes 1 or 2, as it uses the Portal's Image Service settings. A certificate is not required.
If you are using Security Mode 3, import the certificate of the CA that signed the Image Service and/or Portal certificate into Oracle WebCenter Collaboration. For details, see Importing CA Certificates.
Enable firewall access on port 28282 for communication between Oracle WebCenter Collaboration and the CNS. This is a UDP heartbeat port that Oracle WebCenter Collaboration uses to determine the CNS is alive without incurring a TCP handshake delay. You must add this port to the firewall.
If the host/port of the normal Image Service URL used by browsing users is not accessible from Oracle WebCenter Collaboration (for example, the Image Service is on a different machine than Oracle WebCenter Collaboration), you must change the jscontrols component that Oracle WebCenter Collaboration uses. This problem generates error messages that are displayed in the Calendar portlets. To avoid these errors:
Open the Oracle WebCenter Collaboration config.xml configuration file, located in PT_HOME/ptcollab/version/settings/config.
In the following line, set the URL to the value of ImageServerConnectionURL set in the portal portalconfig.xml configuration file.
<jscontrols> <imageServerConnectionURL>[URL]</imageServerConnectionURL>
Import the CA certificate from the Image Service and Portal into Oracle BPM Suite. For details, see Importing CA Certificates.
This section describes the various authentication options for an Oracle WebCenter deployment. It provides details on the following topics:
Delegating Authentication,: By default, Oracle WebCenter performs authentication using credentials stored in the Oracle WebCenter Interaction portal database. Beyond basic portal authentication, Oracle WebCenter can delegate authentication to other back-end systems, such as:
A remote authentication tier, such as an LDAP service. For details, see Delegating to a Remote Authentication Tier.
An SSO Provider such as Oracle Access Manager. For details, see Delegating to an SSO Provider.
Windows Integrated Authentication. For details, see Delegating to Windows Integrated Authentication.
Access Control Lists and Profile Sources,: Access control lists allow permissions to be granted to users and groups, and user and group properties can be pulled from back-end services and mapped to portal users and groups.
Brokering Credentials,: Authenticated users can have their credential information brokered to other back-end services, allowing a single login to the portal to enable access to various systems.
The portal can be configured to delegate authentication to various other systems, including remote authentication tiers such as LDAP servers and Active Directory, SSO providers such as Oracle Access Manager or Netegrity, and Windows Integrated Authentication (WIA). The following sections describe delegating authentication to these systems.
Authentication can be delegated to a remote authentication tier by implementing an Oracle WebCenter authentication service. The authentication service serves two roles: synchronization and authentication.
Synchronization against a back-end authentication source imports users and groups into the Oracle WebCenter Interaction portal database. This must be done before the portal user can authenticate against the back-end authentication source. Passwords are not imported. This allows portal object permissions to be mapped to external users and groups, while maintaining authentication solely by the back-end authentication source.
Authentication allows the portal to query a back-end authentication source using a user's credentials. The sequence of events in the process is as follows:
The user browses to the main portal page and is presented the login screen. User enters credentials.
Oracle WebCenter Interaction sends a request to the back-end authentication source using the configured Oracle WebCenter authentication service.
The back-end authentication source returns validity of user credentials.
If the user is authenticated, access to their profile in the portal is granted. If the user is not authenticated, they are presented with the login screen.
Oracle WebCenter Interaction stores credentials in memory, and the user is identified by a browser cookie, if configured to do so. This allows the user to be logged in automatically next time he visits the portal.
Oracle provides pre-made authentication services supporting LDAP and Active Directory back-end systems. In addition, you can develop custom authentication services to authenticate against any back-end system.
For details on configuring a pre-made authentication service, see the Oracle Fusion Middleware Administrator's Guide for Oracle WebCenter Interaction.
For details on creating a custom authentication service, start with the Oracle Fusion Middleware Web Service Developer's Guide for Oracle WebCenter Interaction.
Delegating authentication to an SSO provider can circumvent the Oracle WebCenter Interaction login screen and present the user with the login method of the SSO provider. This allows authentication by non-Web form mechanisms, such as keycards or biometric authentication.
The sequence of events of this process as follows:
The user browses to the main portal page address.
The portal forwards this request to the SSO provider.
The SSO provider determines whether the user is already authenticated or needs to be authenticated. This might be done by checking the user's browser cookies or by another method.
If the user is not authenticated, the SSO provider does what is necessary to gather credentials and authenticate the user.
The SSO provider returns the user to the portal and instructs Oracle WebCenter Interaction to grant the user access to his profile.
Delegating to Windows Integrated Authentication (WIA) is similar to delegating to an SSO source. With WIA, the user's credentials are the same as their Windows network credentials. When the user browses to the portal page, the portal uses Windows to authenticate the user.
Prior to authenticating with WIA, user information must be crawled into the portal database using an Active Directory authentication source.
The sequence of events in the WIA authentication process is as follows:
The user logged into a Windows network browses to the main portal page.
The Portal returns a 401 Unauthorized message to the user browser.
The browser and portal perform the WIA handshake to validate the user.
The portal accepts the authentication and grants access to the user's profile.
For WIA to work, the user must be logged into a Windows network and be using a browser, such as Internet Explorer, that supports the WIA handshake. WIA will fail over an HTTP proxy.
Access Control Lists (ACLs) allow users and groups to be granted permission to use and modify objects in the portal. Portal users who authenticate with any of the methods described in the section Delegating Authentication, can be identified within the portal database and added to object ACLs.
A profile service uses an authentication service to pull user properties from back-end systems such as LDAP services. Properties in the back-end system are mapped to Oracle WebCenter Interaction portal properties and synchronized with the authentication service.
For details on configuring ACLs or configuring profile services, see the Oracle Fusion Middleware Administrator's Guide for Oracle WebCenter Interaction.
For details on developing profile services, start with the Oracle Fusion Middleware Web Service Developer's Guide for Oracle WebCenter Interaction.
The credentials of a logged in user can be made available to other systems being accessed via the Oracle WebCenter Interaction portal. This allows applications in the portal to display information from systems such as email or other enterprise applications without requiring for the user to log into each of these systems separately.
There are various ways Oracle WebCenter Interaction can pass credentials to back-end systems:
PassThrough: The credentials the user supplied at login can be sent to the remote tier as a Basic Authentication header. This is useful if both the portal login and the back-end system login are based on the same authentication source, such as an LDAP service.
Preferences: Preferences can be created to hold the user's credential, to be set individually by the end user. Preferences are stored encrypted in the portal database and controlled by the end-user.
UserInfo: User properties are mapped to credential information stored in an LDAP service or other back-end source. Credentials are automatically populated for each user.
SSO: An SSO token can be forwarded to the remote tier. This only works if the remote tier application can accept an SSO token. In cases where an SSO token is not accepted, some SSO Providers provide an API to convert the SSO token to name and password. This is dependent on the SSO vendor and the configuration of the SSO provider.
Lockbox: User credentials can be stored in a lockbox in the Oracle WebCenter Interaction credential vault. The credential vault provides a central repository that securely stores and manages credentials. Portlets that need credentials to access back-end systems can securely retrieve appropriate user credentials.
For details on brokering credentials to existing applications, see the Oracle Fusion Middleware Administrator's Guide for Oracle WebCenter Interaction.
For details on developing portlets that use brokered credentials, start with Oracle Fusion Middleware Developer's Guide for Oracle WebCenter WSRP Producer for .NET.
|
 Copyright © 2011, Oracle and/or its affiliates. All rights reserved. Legal Notices |
|
