Securing Provider Communications If the security of exportingimporting

7-58 Oracle Fusion Middleware Developers Guide for Oracle Portal default. However, if you want greater security, you can encrypt the data. Refer to Section 7.2.8.3.4, Encrypting Personalization Data for Transport . 7.2.8.3.4 Encrypting Personalization Data for Transport By implementing the oracle.portal.provider.v2.security.CipherManager class for your provider, you can encrypt the personalization data prior to exporting it. Upon import, the cipher manager is invoked again to decrypt the data. Refer to Section 7.2.8.3.6, Encrypting Personalization Data Example .

7.2.8.3.5 Exporting by Reference As mentioned previously, the default behavior for

exporting of portlets is to include the actual personalization data in the transport set. For a more secure transport, you can code your portlet such that the personalizations are exported using pointers rather than by including the actual preference data. When the transport set is imported, the target Oracle Portal instance sends the pointer back to the Web provider, which then has the opportunity to reassociate the actual data with the new portlet instance. Refer to Section 7.2.8.3.7, Exporting by Reference Example .

7.2.8.3.6 Encrypting Personalization Data Example To encrypt personalization data in your

Web provider, you need to create your own cipher manager and associate it with your portlet provider. This example provides a simple, insecure cipher manager for illustrative purposes only. To implement a secure implementation of the cipher manager for your production system, you would need to significantly extend this sample. Some of the issues you would need to consider for a production implementation are as follows: ■ Do not hold the key object in memory. Read it from a persistent store as necessary. ■ Use the providers PreferenceStore API supported by a DBPreferenceStore to work in the clustered case. ■ On import, if the cipher manager instance obtained from provider.xml matches the class name returned in the SOAP message, that CipherManager instance is used to perform the decryption. Hence, the instance maintained in the portletprovider definition may be configured using any applicable means for example, tags in provider.xml or JNDI variable and that configuration is reused on import. To encrypt personalization data in your Web provider, do the following: Note: If you choose to encrypt your Web providers for export using the cipher manager, you must also devise your own key management strategy for the encryption algorithm. Note: When exporting across security zones, exporting by reference may not work effectively. In general, you should only employ export by reference when transporting within the same general security environment. Note: The following sample is for illustrative purposes only. You would need to significantly enhance it for use in a production environment. Enhancing Java Portlets 7-59 1. Create a cipher manager class, InsecureCipherManager. This class will be used for encryption and decryption of personalization data exported from or imported to a Web provider. A base64 encoded, hard coded secret key is used with the DES algorithm supplied by the default javax.crypto provider of the underlying Java Runtime Environment. As a result, this particular sample is insecure because the encoded key can be recovered by a malicious party simply by decompiling the byte code. package oracle.portal.sample.v2.devguide.tx; import java.io.IOException; import java.security.GeneralSecurityException; import javax.crypto.Cipher; import javax.crypto.SecretKey; import javax.crypto.SecretKeyFactory; import javax.crypto.spec.DESKeySpec; import oracle.portal.provider.v2.ProviderException; import oracle.portal.provider.v2.security.CipherManager; import sun.misc.BASE64Decoder; public final class InsecureCipherManager implements CipherManager { Base64 encoded external form of a javax.crypto.SecretKey which was generated for the DES algorithm. This is completely insecure Anyone can decompile the bytecode and recostitue the key. A more secure implementation would implement a key management policy in a java.security.KeyStore. private static final String sEncodedKey = UTJds807Arw=; Generated from the insecure encoded form in sEncodedKey. private SecretKey mKey; Transforms the input data to a more secure form, in a single operation, using the DES cryptographic algorithm along with a statically defined secret key. param toEncode the input data. return an encoded form of the input data. throws ProviderException if an error occurs during transform. public final byte[] encodebyte[] toEncode throws ProviderException { try { Cipher c = Cipher.getInstanceDES; c.initCipher.ENCRYPT_MODE, getSecretKey; return c.doFinaltoEncode; } catch GeneralSecurityException gse { throw new ProviderExceptiongse; } catch IOException ioe { Note: This sample makes use of the javax.crypto package, which is optional in Java 1.3 and must be installed manually. In Java 1.4, though, this package is present by default.