Skip to end of metadata
Go to start of metadata

You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 9 Next »

Overview

In order to implement Aes 256 bit encryption is was necessary override the existing encryption service. To accomplish this we re-referenced the "encryptionService"  spring bean to point to the new encryption service edu.uconn.kuali.rice.core.service.impl.AesEncryptionServiceImpl.

Wiring it All Together.

Rice 2.x no longer uses the rice config parameter "rice.additionalSpringFiles"  to list override spring files instead each module requires a parameter rice.[module].additionalSpringFiles that lists the override files for that particular module. The encryption service is part of the "kr" module as such we added the following line <param name="rice.kr.additionalSpringFiles">classpath:edu/uconn/kuali/rice/config/UConnKrOverrideSpringBeans.xml</param> to the Rice and KFS configuration files.

 

Encryption Service

Encryption is located in 2 places - inside the KFS application and inside the oracle schemas. For the system to properly function, the key in oracle should match the key in the application, and the encrypted data must be encrypted with that key.

Application Server

The class edu.uconn.kuali.rice.core.service.impl.AesEncryptionServiceImpl handles the encryption inside the KFS application. The service is referenced solely by the OJB configuratiion. Each encrypted field contains a conversion property in the OJB configuration of the business object that contains the field. The conversion property must be set to org.kuali.rice.core.framework.persistence.ojb.conversion.OjbKualiEncryptDecryptFieldConversion. This class uses the encryption service to encrypt or decrypt data when being read or stored.

AES Encryption Service

The AesEncryptionServiceImpl class uses the Java encryption library to implement the AES encryption algorithm with cipher block chaining and a static initialization vector.

security key

Each server stores the encryption key in a secure location within the security.properties file. This key must match the key used to encrypt the data in order for KFS to function properly.

Encrypted fields
  • org.kuali.kfs.pdp.businessobject.AchAccountNumber=achBankAccountNbr
  • org.kuali.kfs.pdp.businessobject.PayeeACHAccount=bankAccountNumber
  • org.kuali.kfs.sys.businessobject.Bank=bankAccountNumber
  • edu.uconn.kuali.kfs.cr.businessobject.CheckReconciliation=bankAccountNumber
  • org.kuali.kfs.module.ar.businessobject.Customer=customerTaxNbr
  • org.kuali.kfs.fp.businessobject.DisbursementVoucherWireTransfer=disbVchrPayeeAccountNumber
  • uconn.edu.kuali.kfs.tax.businessobject.Payee=headerTaxNumber
  • edu.uconn.kuali.kfs.fp.businessobject.ProcurementCardHolder=transactionCreditCardNumber
  • edu.uconn.kuali.kfs.fp.businessobject.ProcurementCardHolderDetail=creditCardNumber
  • org.kuali.kfs.fp.businessobject.ProcurementCardTransaction=transactionCreditCardNumber
  • org.kuali.kfs.vnd.businessobject.VendorHeader=vendorTaxNumber
  • org.kuali.kfs.vnd.businessobject.VendorTaxChange=vendorPreviousTaxNumber

Additionally, the krew_doc_hdt_t table contains a column doc_hdr_cntnt that is a CLOB data type containing an encrypted XML string. Likewise, the krns_maint_doc_t table has a column doc_cntnt that is a CLOB data type containing encrypted XML string containing the full maintenance document content. These 2 columns are not re-encrypted by the cleanse program due to the number of rows and size of columns. Hence, after a refresh from production they contain data that is encrypted with the production key.

Database 

Each KFS schema has the EncryptionService included. Encryption on the database is used only for 2 reasons - the data mart and the cleanse process. The data mart only uses the production schemas. The cleanse process is only used in non-production schemas. The encryption service in oracle is referenced through a function, decrypt_string(). The encrypted field is passed to the decrypt_string function.

EncryptionService

The EncryptionService class is a java class stored inside of Oracle. Oracle refers to this as a Java object. The type is class. This class is a copy of the AesEncryptionServiceImpl class, slightly modified in order to minimalize the dependencies and remove any dependencies not available from the Oracle version of Java.

Calling the EncryptionService

The EncryptionService class is referenced by calling a function, decrypt_string and passing the column that needs to be decrypted. For example,

select bnk_cd, decrypt_string(bnk_acct_nbr) from fp_bank_t;

Java objects

The EncyrptionService class requires one important dependency not available from the Oracle Java libraries. This is the Base64 class from the Apache commons codec library. Therefore this class must be loaded into the Oracle schema in order for the EncryptionService to function. 

Commons Codec library 

The commons codec library must be loaded in to Oracle. Since this library exists on the application servers, it is best to use the Oracle client loadjava tool from the application server. 

loadjava -user <connection_string> -r -v /usr/share/tomcat6/webapps/kfs-upg/WEB-INF/lib/commons-codec-1.6.jar

To drop an existing EncryptionService object

echo "drop java source EncryptionService;" | sqlplus <connection_string> 

To load the Encryption class

loadjava -user <connection_string>  -r -v EncryptionService.java

To verify java objects are valid 

Expand the Java icon in SQLDeveloper. Click on a java object and check the status. If the status is valid, it means the object is loaded and compiled and ok to be used. If it is invalid it means that the object was imported from another external source and not available to be referenced.

 

 

 

 

 

  • No labels