WebCenter Sites provides secure server access to protect your system from internal or external security attacks. All access is protected through cryptographic encryption of sensitive information whether located in files or within the server itself. It is important for all organizations to establish security standards to ensure that important information is not compromised
Audit Trail Information reports are described in this chapter. They are:
WebCenter Sites secures the system by default and provides several options to further tighten security to meet your installation's requirements.
The system comes installed with a secured key store that provides the necessary encryption keys to properly handle passwords and data exchanges across the network through encryption techniques. This ensures that sensitive information is not visible to unauthorized individuals which could compromise the security of your system.
The system has the option to provide an external key store so that the creation and administration of encryption keys can be controlled by the system administrator. An external key store uses standard Java cryptography to create and maintain symmetrical encryption keys.
The system has the option to provide an external credential store rather than a Java key store for increased security. A credential store facility uses Oracle's advanced cryptography to create and maintain symmetrical encryption keys. The credential store location is identified by a properly configured JPS (Java Platform Security) provider. When used with the WebLogic application server, access and modification of the credential store is protected by JPS permissions. Only authorized programs are permitted to access the credential store for reading, modification, or both.
The use of standard Java cryptography or Oracle's advanced cryptography functionality depends on the type of storage for external encryption keys. The system does not support inter mixing of cryptography packages, they are mutually exclusive in all cases. The external key store (type is JCEKS) must use the standard Java cryptography package. The Oracle Credential Store Facility (CSF) only allows encryption keys created by the Oracle Security Developer Tools (OSDT). Because encryption keys created by one cryptographic package will not be compatible across all types of key stores, you should choose the type of store that suits your security needs and use it in all cases.
For components that require cryptographic support across application server contexts or machines (such as required for clustered configurations) or both the same encryption keys must be available. In other words, where a data value is encrypted at one location it must be decrypted using the same key at the destination location. This means that you must use copies of the central key store each place where encryption and decryption are necessary.
The replication and sharing of encryption keys through a key store or credential store varies on your environment and is not discussed in this document.
Configuration of the cryptography package and external encryption key stores is controlled by the SitesSecurityContext.xml configuration file. This file must reside on the class path of the programs that require it. Customizing this file is covered later in the next section. The Sites product uses a standard naming convention for associating encryption keys to different functions within the product. There is not a single encryption key used in all cases. This permits changing the key by functional use at any time without affecting other functions. There are four associative names used, for any key store type, which are:
masterkey – reserved for future use
tokenskey – the encryption key used by the Sites token generator
generalkey – the encryption key used for all encrypted POST exchanges and sensitive information located in external files.
passwordkey – the encryption key used when the user password in the database is encoded by symmetrical encryption.
Note:
For a JCEKS key store, the storage of cryptography keys provides password protection for every key. This version of Sites does not make use of this capability and expects each of the above keys to have the same password as the key store itself.There are two types of encryption key storages that can be used:
JCEKS is the standard key store facility to housing symmetrical encryption keys. Keys stored in this facility must be created and used with the standard Java cryptography functions. Although this type is universal it is provider specific and care must be observed not to mix a key store created by one provider and used by another. This is tied to the Java runtime used to run your applications. Oracle or Sun Microsystems use a standard JCE provider to create and retrieve encryption keys. IBM provides their own Java runtime which has a different key store provider. Although it is possible to modify the IBM security environment to accept the standard Java JCE provider, the steps to do this are beyond the scope of this document.
Oracle Credential Store Facility (CSF) is a very secure key storage facility that is accessed through Java Platform Security (JPS). This facility can be used instead of JCEKS key store across all environments and is not provider specific as it is an integral part of Oracle security. Only symmetrical encryption keys created by Oracle OSDT (Oracle Security Developer Tools) can be stored in this facility. In the WebLogic environment, this credential store is protected by JPS permissions. Programs that access or manipulate contexts of the credential store must be granted permission. Those programs which do not have the proper permission are denied access. For situations requiring the highest level of security, this is the preferred option.
The SitesSecurityContext.xml file controls all aspects of the security environment which WebCenter Sites and its related utilities operate within. It is a Spring configuration file which instantiates the implementation classes for cryptography, encryption key storage, CSRF token generation, and internal security processing within the Sites server. It is an integral part of security between the various system components.
When it is necessary to change system defaults to satisfy varied security requirements this file is modified to provide the desired overrides. There must be a copy of this configuration file, with the modifications, available to each component (that is, WebCenter Sites utility program, server component, REST client) to ensure that the proper cryptographic package is used with access to the required key store. Failure to provide the proper configuration and associated key store to all components will cause part of the system to cease functioning.
<?xml version="1.0" encoding="UTF-8"?>
<beans xmlns="http://www.springframework.org/schema/beans"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xmlns:context="http://www.springframework.org/schema/context"
xsi:schemaLocation="
http://www.springframework.org/schema/beans
http://www.springframework.org/schema/beans/spring-beans-2.5.xsd
http://www.springframework.org/schema/context
http://www.springframework.org/schema/context/spring-context-2.5.xsd">
<!-- Crypto support package -->
<bean id="cryptoPackage"
class="com.fatwire.security.common.JavaSecurityCrypto" />
<!-- Credential storage (using JCEKS repository) support package -->
<bean id="credentialPackage"
class="com.fatwire.security.common.JCEKSCredentialStore" >
<property name="keyStoreJar"
value="com/fatwire/security/common/data/WCSitesDefault.keystore" />
<property name="IBMStoreJar"
value="com/fatwire/security/common/data/WCSitesDefaultIBM.keystore" />
</bean>
<!-- CSRF Token generation/validation package (Sites server only) -->
<bean id="tokenPackage" class="com.fatwire.auth.SecurityTokenImpl" />
<!-- Security Basis ... This is the root of all evil -->
<bean id="securityBasis"
class="com.fatwire.security.common.SecurityBasis" >
<property name="securityCrypto" ref="cryptoPackage" />
<property name="securityToken" ref="tokenPackage" />
<property name="credentialStorage" ref="credentialPackage" />
</bean>
<!-- Security Context (Sites server only)-->
<bean id="securityContext"
class="COM.FutureTense.Security.Context.AdvancedSecurityContextImpl" >
<property name="securityBasis" ref="securityBasis" />
</bean>
</beans>
The SitesSecurityContext.xml file is broken down into five beans; three are mandatory (cryptoPackage, credentialPackage, and securityBasis) and two used only by the Sites server (tokenPackage and securityContent). Once modified, the revised file must be placed on the class path of all components that require it.
The beans in this file are described as:
cryptoPackage – this bean specifies which cryptographic package is initialized. There are two choices, expressed as a fully qualified class name:
com.fatwire.security.common.JavaSecurityCrypto – using Java runtime
com.fatwire.security.common.OracleSecurityCrypto – using OSDT. This cryptography package must be specified if the Oracle Credential Store Facility is to be used.
credentialPackage – this bean specifies which key storage is initialized. There are three choices, expressed as a fully qualified class name:
com.fatwire.security.common.JCEKSCredentialStore – default support using JCEKS key stores.
com.fatwire.security.common.DefaultCredentialStore – standard CSF implementation for all external programs or application servers other than WebLogic.
com.fatwire.security.common.WeblogicCredentialStore – WebLogic specific CSF implementation.
tokenPackage – this bean is required for the Sites server only. The class keyword selects the proper class implementation (default is com.fatwire.auth.SecurityTokenImpl). You have the option to implement your own security token generator which implements the securityToken interface.
securityBasis – this bean binds all security components together and is not to be modified. The property entries refer to other bean definitions. The securityToken property is only specified on the Sites server.
securityContext – this bean is required for Sites server only. It defines the class which handles all internal security processing. This bean is not to be modified.
This file must be available on the class path for each application that requires cryptographic encryption and access to a key store facility. Copies of this file must be configured with the same cryptography and credential store packages. The following components require a properly configured copy of this file.
Sites Content web application server WEB-INF/classes
Sites CAS web application server WEB-INF/class (when CAS is the configured authenticator)
Sites TokenAuthority web application servlet (when OAM is the configured authenticator)
Sites REST client application programs
Sites utility programs (CatalogMover, PropertyEditor, XmlPost, CSE)
It is possible to implement mixed key storage methods provided the encryption keys are created with the same salts. For example, CAS can be configured with Java cryptography and JCEKS key storage which can be used with Sites content server using Oracle cryptography and CSF key storage. Both key stores are populated with the named symmetrical encryption keys using the identical salts. Although this will work it is recommended to use a single key storage methodology for all applications for simplicity.
There are several utilities available with the Sites system to aide in the creation and maintenance of encryption key storage. These utilities are located in site-security-11.1.1.8.0.jar and are executed by invoking by the specific class names from the java command. When running, it is necessary to define the class path for all the necessary jars required by the utilities. The following is a sample shell script that will run one of the utility classes when the class name is supplied as the first argument:
#!/bin/sh
# Set JAVA_HOME
JAVA_HOME="/fmw/jdk/bin"
# Set CLASS_PATH
CLP="./:sites-security-11.1.1.8.0.jar:commons-logging-1.1.1.jar:spring-2.5.5.jar"
CLP="${CLP}:/fmw/middleware/oracle_common/modules/oracle.osdt_11.1.1/osdt_core.jar"
CLP="${CLP}:/fmw/middleware/oracle_common/modules/oracle.osdt_11.1.1/osdt_core_fips.jar"
CLP="${CLP}:/fmw/middleware/modules/com.oracle.jps-common_1.0.0.0.jar"
CLP="${CLP}:/fmw/middleware/modules/com.oracle.jps-api_1.0.0.0.jar"
CLP="${CLP}:/fmw/middleware/modules/com.oracle.jps-internal_1.0.0.0.jar"
CLP="${CLP}:/fmw/middleware/modules/com.oracle.jps-mbeans_1.0.0.0.jar"
CLP="${CLP}:/fmw/middleware/modules/com.oracle.jps-unsupported-api_1.0.0.0.jar"
CLP="${CLP}:/fmw/middleware/modules/com.oracle.identitystore_1.0.0.0.jar"
CLP="${CLP}:/fmw/middleware/modules/com.oracle.oraclepki_1.0.0.0.jar"
CLP="${CLP}:/fmw/middleware/modules/com.oracle.osdt_cert_1.0.0.0.jar"
$JAVA_HOME/java -cp ${CLP} -Doracle.security.jps.config=./config/jps-config.xml
com.fatwire.security.util.$1 $2 $3
com.fatwire.security.util.CreateDefaultKeyStore.class: This Sites utility will create the key store and populate it automatically with a randomly generated set of Java encryption keys. It requires one argument: key store filename. The password for the key store must be supplied when prompted for on the system console. The password that is entered at the console prompt must be provided in the SitesSecurityContext.xml configuration file.
Arguments (positional):
Keystore-name Keystore-password
Example:
java -cp sites-security-11.1.1.8.0.jar com.fatwire.security.util.CreateDefaultKeyStore mystore.keystore
com.fatwire.security.util.CreateDefaultCredentialStore: This utility will create the Oracle Credential Store Facility (CSF) cwallet.sso file and populate it automatically with a randomly generated set of Oracle encryption keys. The current JPS configuration is used to locate and update the cwallet.sso file. If there is no credential store, then it will be created. The replace argument should be set to yes if the utility should replace any Sites encryption keys that already exist.
Arguments:
product=sites
replace=no | yes (default is no)
com.fatwire.security.util.ExportFromJCEKS.class will extract the salts for each of the Sites keys in the currently active key store and write the values to the export.keys file in the working directory. The export file is used as input to one of the import utility programs listed below.
Arguments: (optional)
export.keys
Example:
java -cp sites-security-11.1.1.8.0.jar;commons-logging-1.1.1.jar;spring-2.5.5.jar com.fatwire.security.util.ExportFromJCEKS
com.fatwire.security.util.ImportToJCEKS.class will take the extracted salts from the export.keys file, create each of the Sites encryption keys using the associated salt, and add to the output key store. It requires two arguments: key store filename and export keys file. The password for the key store must be supplied when prompted for on the system console. The password that is entered at the console prompt must be provided in the SitesSecurityContext.xml configuration file. If the key store does not exist, then it will be automatically.
Arguments (positional):
Keystore-name export.keys
Example:
java -cp sites-security-11.1.1.8.0.jar;commons-logging-1.1.1.jar;spring-2.5.5.jar com.fatwire.security.util.ImportToJCEKS mystore,keystore export.keys
com.fatwire.security.util.ImportToCSF.class will take the extracted salts from the export.keys file, create each of the Sites encryption keys using the associated salt, and add to the output credential store. If the credential store does not exist, then it will be automatically created. The output credential store is defined by the location property in the jps-config.xml.
Arguments:
product=sites
import=export.keys
replace=no | yes (default is no)
Example:
java -cp sites-security-11.1.1.8.0.jar;commons-logging-1.1.1.jar;spring-2.5.5.jar com.fatwire.security.util.ImportToCSF
The JCEKS key store which is used to store Java.security encryption keys. It is necessary to create this file and populate it with the encryption key set required by Sites. The key store can be created manually using the Java keytool utility located in the Java JRE bin folder, or using a creation utility class that is provided in the sites-security jar (com.fatwire.security.util.CreateDefaultKeyStore.class). The sites utility will create the key store and populate it automatically with a randomly generated set of Java encryption keys.
The key store requires two arguments:
arg[0] = key store filename
arg[1] = key store password
This password must be provided in the SitesSecurityContext.xml configuration file. In a minimum configuration (CS and CAS), there must be a SitesSecurityContext.xml file in each servlet context's class path that points to the proper key store.
If you are not using the CreateDefaultKeyStore utility, use the Java keytool utility supplied with the Java runtime. The store type must be JCEKS. You must create four keys with the following names listed below. Each encryption key is assigned the same password as the key store itself.
masterkey – reserved for future use
tokenskey – the encryption key used by the Sites token generator
generalkey – the encryption key used for all encrypted POST exchanges and sensitive information located in external files.
passwordkey – the encryption key used when the user password in the database is encoded by symmetrical encryption.
For WebSphere, you must create the key store using the IBM Java runtime. You cannot mix IBM runtime processing with a key store created with a normal Java runtime.
If you are using the CreateDefaultKeyStore utility, specify the name and password as arguments when running the class. The utility will create a complete set of the above keys.
Depending upon how you create the key store, the SitesSecurityContext.xml file must be modified for CS and a copy provided to override the default setup for CAS. You must replace the properties in the credentialPackage bean with a property keyStoreFile with a value that is the fully qualified file descriptor where the key store resides in the file system. The property keyStorePassword must provide the key store password provided when the key store was created. Changing key stores does not affect password encoding in the Sites database. This ensures you can always log into the system even when key stores are not working properly. However, all external passwords stored in INI files will have an encryption from the internal key store and no longer be able to be encrypted. All passwords in external files should be changed back to their clear text values. Then after the new key store is in place, use the property editor to force each password to be encrypted using the new keys. Remember to include a SitesSecurityContext.xml file to be accessed by the PropertyEditor utility. Sometimes it is necessary to transfer the same salts used to create encryption keys from one key store to another. An example is creating mixed provider key stores in an environment with Java and IBM runtimes (used within WebSphere). The utility classes included in the sites-security jar file are provided to help this transition.
com.fatwire.security.util.ExportFromJCEKS.class will extract the salts for each of the keys in the currently active key store and write the values to the export.keys file in the working directory.
com.fatwire.security.util.ImportToJCEKS.class will take the extracted salts from the export.keys file, create each of the Sites encryption keys using the associated salt, and add to the output key store. If the key store does not exist, then it will be automatically created.
Arguments:
product=sites
import=export.keys
replace=no | yes
The Sites server employs the Enterprise Security API to check for and prevent security vulnerabilities that may occur from injection of malicious web data. The validation can be customized to meet tighter control over the content of HTTP headers and incoming data. The validation expressions contained in the ESAPI.properties file can be modified; this file is included when you install the Sites server. This file resides in the Sites WEB-INF/classes folder.
Further information about ESAPI is available at the following link: https://www.owasp.org/index.php/Category:OWASP_Enterprise_Security_API